Re: Anybody working on tidspbridge?
* Suman Anna s-a...@ti.com [140708 11:40]: 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. I agree, not much has improved with this driver since it got added into staging except just compile 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 V2] ASoC: omap-mcbsp: Use devm_snd_soc_register_component
On Tue, Jul 08, 2014 at 09:55:23PM +0530, Manish Badarkhe wrote: Replaced snd_soc_register_component with its devres equivalent, devm_snd_soc_register_component. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH V2] ASoC: omap-dmic: Use devm_snd_soc_register_component
On Tue, Jul 08, 2014 at 10:23:17PM +0530, Manish Badarkhe wrote: Replaced snd_soc_register_component with its devres equivalent, devm_snd_soc_register_component. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices
* Suman Anna s-a...@ti.com [140708 10:57]:
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.
OK since we already have some .dts entries with ti,mbox-num-fifos and
ti,mbox-num-users I'd use those for now. Adding parsing for a generic
property can be done later on.
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.
OK
Tony,
Depending on the agreement here, I may have to respin the OMAP
mailbox DT/hwmod cleanup series [1]
OK let me know.
Regards,
Tony
[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: [PATCH v3 0/7] ARM: dts: AM43x: Add devcice tree nodes
* Keerthy j-keer...@ti.com [140708 22:40]: 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. Are the .dts changes safe to apply separately without breaking anything? 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 1/3] regulators: tps65218: fix DCDC4 linear voltage range
On Tue, Jul 08, 2014 at 02:09:12PM -0500, Felipe Balbi wrote: The second range of this particular regulator, starts at 1.60V, not as 1.55V as it was originally implied by code. Applied all, thanks. Please use subject lines consistent with the style for the subsystem - these even vary within the series! signature.asc Description: Digital signature
[PATCH V2 0/2] ARM: DRA7: Add RTC hwmod and dt entries
This series adds hwmod entry and dt node for RTC. Tested on DRA7: logs can be seen here: http://hastebin.com/jaxogatuta.vhdl Lokesh Vutla (2): ARM: DRA7: hwmod: Add data for RTC ARM: dts: DRA7: Add node for RTC arch/arm/boot/dts/dra7-evm.dts|1 + arch/arm/boot/dts/dra7.dtsi |9 +++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 + 3 files changed, 51 insertions(+) -- 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/2] ARM: dts: DRA7: Add node for RTC
Add node for RTC.
And also making RTC regulator always-on, as RTC should be powered
always.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[n...@ti.com: update with rtc crossbar number]
Signed-off-by: Nishanth Menon n...@ti.com
---
This patch depends on the crossbar dt patch series by Sricharan:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106910.html
arch/arm/boot/dts/dra7-evm.dts |1 +
arch/arm/boot/dts/dra7.dtsi|9 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..bca6d4a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -249,6 +249,7 @@
regulator-min-microvolt = 105;
regulator-max-microvolt = 105;
regulator-boot-on;
+ regulator-always-on;
};
ldoln_reg: ldoln {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 55a6cd4..46779197 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -828,6 +828,15 @@
ti,hwmods = sata;
};
+ rtcss@48838000 {
+ compatible = ti,am3352-rtc;
+ reg = 0x48838000 0x100;
+ interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = rtcss;
+ clocks = sys_32k_ck;
+ };
+
omap_control_usb2phy1: control-phy@4a002300 {
compatible = ti,control-phy-usb2;
reg = 0x4a002300 0x4;
--
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/2] ARM: DRA7: hwmod: Add data for RTC
Add hwmod data for RTC
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
Changes since V1:
Rebased on top of linux-next 20140708.
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +
1 file changed, 41 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..d8032b9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = {
};
/*
+ * 'rtcss' class
+ *
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = {
+ .sysc_offs = 0x0078,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
+ .name = rtcss,
+ .sysc = dra7xx_rtcss_sysc,
+};
+
+/* rtcss */
+static struct omap_hwmod dra7xx_rtcss_hwmod = {
+ .name = rtcss,
+ .class = dra7xx_rtcss_hwmod_class,
+ .clkdm_name = rtc_clkdm,
+ .main_clk = sys_32k_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'sata' class
*
*/
@@ -2344,6 +2376,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per3 - rtcss */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = {
+ .master = dra7xx_l4_per3_hwmod,
+ .slave = dra7xx_rtcss_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = {
{
.name = sysc,
@@ -2673,6 +2713,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l3_main_1__qspi,
+ dra7xx_l4_per3__rtcss,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
dra7xx_l4_cfg__smartreflex_mpu,
--
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] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Tested-by: Kishon Vijay Abraham I kis...@ti.com
---
Changes from v1:
* changed the clock domain to pcie_clkdm
* Added PCIe as a slave port for l3_main.
Boot log for dra7xx can be found at http://paste.ubuntu.com/7769402/
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 73 +
1 file changed, 73 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 6ff40a6..2f37ca8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+ .name = pcie,
+};
+
+/* pcie1 */
+static struct omap_hwmod dra7xx_pcie1_hwmod = {
+ .name = pcie1,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = pcie_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 */
+static struct omap_hwmod dra7xx_pcie2_hwmod = {
+ .name = pcie2,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = pcie_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'PCIE PHY' class
*
*/
@@ -2448,6 +2485,38 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main_1 - pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pcie1 = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_pcie1_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie1_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 - pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pcie2 = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_pcie2_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie2_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg - pcie1 phy */
static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
.master = dra7xx_l4_cfg_hwmod,
@@ -2813,6 +2882,10 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l4_cfg__ocp2scp3,
+ dra7xx_l3_main_1__pcie1,
+ dra7xx_l4_cfg__pcie1,
+ dra7xx_l3_main_1__pcie2,
+ dra7xx_l4_cfg__pcie2,
dra7xx_l4_cfg__pcie1_phy,
dra7xx_l4_cfg__pcie2_phy,
dra7xx_l3_main_1__qspi,
--
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 1/3] arm: dra7xx: Add hwmod data for MDIO and CPSW
Hi,
Can you please check the comments below so we don't have to
add duplicate data just to remove it later on.
* Sebastian Andrzej Siewior bige...@linutronix.de [140708 11:43]:
+
+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 },
+};
Why do we need the interrupts here? They should be coming
from the .dts files? Is this numbering with or without
the crossbar?
+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,
+ },
+ { }
+};
Also for the IO range, this should be coming from the .dts
files now?
+static struct omap_hwmod_addr_space dra7xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x48485000,
+ .pa_end = 0x48485000 + SZ_256 - 1,
+ },
+ { }
+};
Here too?
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 2/2] ARM: dts: DRA7: Add node for RTC
* Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: Add node for RTC. And also making RTC regulator always-on, as RTC should be powered always. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com [n...@ti.com: update with rtc crossbar number] Signed-off-by: Nishanth Menon n...@ti.com --- This patch depends on the crossbar dt patch series by Sricharan: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106910.html arch/arm/boot/dts/dra7-evm.dts |1 + arch/arm/boot/dts/dra7.dtsi|9 + 2 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 4adc280..bca6d4a 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? 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 v3 1/7] regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6
On Wed, Jul 09, 2014 at 11:06:27AM +0530, Keerthy wrote: Add fixed_uV fields for dcdc5 and dcdc6. This doesn't apply against current code, can you please check and resend? There were some cleanups from Felipe that just went in, it looks like a collision with them. signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
* Tony Lindgren t...@atomide.com [140708 01:32]:
* 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?
I guess no more comments. Took a look at the patch again, Sekhar, can
you please update the description with what has been discovered in this
thread and repost?
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 2/2] ARM: dts: DRA7: Add node for RTC
Hi Tony, On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: Add node for RTC. And also making RTC regulator always-on, as RTC should be powered always. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com [n...@ti.com: update with rtc crossbar number] Signed-off-by: Nishanth Menon n...@ti.com --- This patch depends on the crossbar dt patch series by Sricharan: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106910.html arch/arm/boot/dts/dra7-evm.dts |1 + arch/arm/boot/dts/dra7.dtsi|9 + 2 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 4adc280..bca6d4a 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? This feeds on to RTC which is a free running clock. So i guess always on is justified no? Regards, Tony 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 v3 1/7] regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6
On Wednesday 09 July 2014 02:44 PM, Mark Brown wrote: On Wed, Jul 09, 2014 at 11:06:27AM +0530, Keerthy wrote: Add fixed_uV fields for dcdc5 and dcdc6. This doesn't apply against current code, can you please check and resend? There were some cleanups from Felipe that just went in, it looks like a collision with them. Yup. They touch the same lines. Those patches were not yet taken before i posted. I will rebase and post. Thanks, 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 1/3] arm: dra7xx: Add hwmod data for MDIO and CPSW
On Wednesday 09 July 2014 12:10 AM, Sebastian Andrzej Siewior wrote:
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 },
+};
This is not proper, NAK
Hwmod is already posted
http://www.spinics.net/lists/linux-omap/msg99039.html
and waiting for Acks and tested-by
Regards
Mugunthan V N
--
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] arm: dts: dra7: Enable CPSW and MDIO for dra7xx EVM
On Wednesday 09 July 2014 12:10 AM, Sebastian Andrzej Siewior wrote:
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
+
Re: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
On 2014-07-08 18:46:39 [+0530], Mugunthan V N wrote: Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC I reverted my patch, applied this one and after boot I got: |platform 48485000.mdio: Cannot lookup hwmod 'davinci_mdio' |cpsw 48484000.ethernet: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info |davinci_mdio 48485000.mdio: failed to get device clock |davinci_mdio: probe of 48485000.mdio failed with error -2 |cpsw 48484000.ethernet: Random MACID = 46:c6:34:6f:8d:c6 | (null): fck is not found with no eth0. Is there something with my setup? I still have the device tree pieces I posted (in case there is something wrong with them). Sebastian -- 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: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
On 2014-07-09 11:55:52 [+0200], Sebastian Andrzej Siewior wrote: On 2014-07-08 18:46:39 [+0530], Mugunthan V N wrote: Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC I reverted my patch, applied this one and after boot I got: Oh me dum dum. I had --dry-run… Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is basically what Tony hasked me to do: No IRQ numbers iomem. Sebastian -- 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: dts: dra7: fixup qspi entry
Hi, On Wednesday 09 July 2014 12:10 AM, Sebastian Andrzej Siewior wrote: 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 Siewiorbige...@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; }; The number is correct and is complaining just because the crossbar stuff is not put in. I had already posted a patch[1] to remove interrupt binding as of now. Hence, NAK for this patch. [1]: https://patchwork.kernel.org/patch/4364341/ -- 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/2] ARM: dts: DRA7: Add node for RTC
* Keerthy a0393...@ti.com [140709 02:36]: On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? This feeds on to RTC which is a free running clock. So i guess always on is justified no? Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on. Also adding temporary dts entries just causes more churn on the dts files which is a PITA for everybody. 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: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
* Sebastian Andrzej Siewior sebast...@breakpoint.cc [140709 03:03]: On 2014-07-09 11:55:52 [+0200], Sebastian Andrzej Siewior wrote: On 2014-07-08 18:46:39 [+0530], Mugunthan V N wrote: Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC I reverted my patch, applied this one and after boot I got: Oh me dum dum. I had --dry-run… Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is basically what Tony hasked me to do: No IRQ numbers iomem. OK great thanks for testing :) 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: gpio-omap: wakeup mask
Hey Tony, all
On 04.07.2014 09:27, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140702 05:12]:
Hi everyone,
we have a device with an am335x and are using some gpios on bank0 to
wake up the device from suspend to ram.
We have some user buttons which are configured in the devicetree as
gpio-keys and one power-key which should wake up the device:
buttons {
power {
label = Power;
gpios = gpio0 6 1;
linux,code = 116;
gpio-key,wakeup;
};
one {
label = One;
gpios = gpio0 11 1;
linux,code = 2;
};
: : :
}
The problem is, that the device wakes up on any trigger on bank 0. No
matter which button was pressed. gpio-key,wakeup seems not to have any
influence.
Now, if I comment the following lines out in drivers/gpio/gpio-omap.c :
set_gpio_trigger(...).
321
322 if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
323_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
324 bank-context.wake_en =
325readl_relaxed(bank-base + bank-regs-wkup_en);
326 }
327
Everything works as expected. But I don't really understand why? Is this
a bug, or does this break something else I have not discovered yet?
The GPIO wake-up events are working from off-idle for omap3
the last time I checked, so sounds like this is some am335x
related issue.
Ok, that sounds reasonable.
What does your bank-context.wake_en mask get set to with this code?
by calling 'echo mem /sys/power/state' followed by a wakeup, I get the
following:
[ 28.738416] PM: Syncing filesystems ... done.
[ 28.779153] Freezing user space processes ... (elapsed 0.003 seconds)
done.
[ 28.790236] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[ 28.801386] PM: Sending message for entering DeepSleep mode
[ 28.935412] bank-context-wake_en = 00080840
[ 28.945935] PM: suspend of devices complete after 133.156 msecs
[ 28.961008] PM: late suspend of devices complete after 8.834 msecs
[ 28.978874] omap_hwmod: cpgmac0: _wait_target_disable failed
[ 28.985940] PM: noirq suspend of devices complete after 18.324 msecs
[ 28.992697] PM: GFX domain entered low power state
[ 28.992697] PM: Could not transition all powerdomains to target state
[ 28.992697] PM: Wakeup source GPIO0
[ 28.992866] bank-context-wake_en = 00080040
[ 29.020974] PM: noirq resume of devices complete after 22.439 msecs
[ 29.028257] bank-context-wake_en = 00080040
[ 29.032840] bank-context-wake_en = 00080840
[ 29.039207] bank-context-wake_en = 00080840
[ 29.043961] bank-context-wake_en = F200
[ 29.048534] bank-context-wake_en = F200
[ 29.053093] bank-context-wake_en = F200
[ 29.057704] bank-context-wake_en = F200
[ 29.062266] bank-context-wake_en = F200
[ 29.066992] bank-context-wake_en = 0006
[ 29.071554] bank-context-wake_en = 0006
[ 29.082499] PM: early resume of devices complete after 6.136 msecs
[ 29.091048] net eth0: initializing cpsw version 1.12 (0)
[ 29.173888] net eth0: phy found : id is : 0x4dd076
[ 29.229388] mmc0: error -110 during resume (card was removed?)
[ 29.235609] dpm_run_callback(): mmc_bus_resume+0x0/0x74 returns -110
[ 29.242272] PM: Device mmc0:0001 failed to resume: error -110
[ 29.293992] PM: resume of devices complete after 204.891 msecs
[ 29.306801] PM: Sending message for resetting M3 state machine
[ 29.313693] Restarting tasks ... done.
Thanks
Pascal
--
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: dts: dra7: fixup qspi entry
On 07/09/2014 12:07 PM, sourav wrote: Hi, Hello, Sourav, The number is correct and is complaining just because the crossbar stuff is not put in. I had already posted a patch[1] to remove interrupt binding as of now. Hence, NAK for this patch. Thank you for explanation. What is the status on the crossbar stuff? Is this comming any time soon? It seems that it is also stalling the networking pieces. [1]: https://patchwork.kernel.org/patch/4364341/ Sebastian -- 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, Jul 07, 2014 at 05:50:09PM +, Paul Walmsley wrote:
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.
I second that. At first sight, the UIO parts look OK to me, but please
make it a new patch series.
Thanks,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] 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 V3:
* Rebased to Latest for/tps65218 branch.
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 e610dad..f0a4028 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, \
- _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,32 +187,32 @@ static const struct regulator_desc regulators[] = {
TPS65218_REG_CONTROL_DCDC1,
TPS65218_CONTROL_DCDC1_MASK,
TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC1_EN,
- 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,
- 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, ldo1_dcdc3_ranges, 2, 0),
+ TPS65218_ENABLE1_DC3_EN, 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,
- 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, 0, 0),
+ TPS65218_ENABLE1_DC5_EN, 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, 0, 0),
+ TPS65218_ENABLE1_DC6_EN, 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, 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 3/3] arm: dts: dra7: fixup qspi entry
* Sebastian Andrzej Siewior bige...@linutronix.de [140709 03:20]: On 07/09/2014 12:07 PM, sourav wrote: Hi, Hello, Sourav, The number is correct and is complaining just because the crossbar stuff is not put in. I had already posted a patch[1] to remove interrupt binding as of now. Hence, NAK for this patch. Thank you for explanation. What is the status on the crossbar stuff? Is this comming any time soon? It seems that it is also stalling the networking pieces. The drivers/irqchip related fixes are queued into linux next, and I'm planning to queue the dts related changes for v3.17. I might have the crossbar stuff in omap-for-v3.17/dt at some point today. Regards, Tony [1]: https://patchwork.kernel.org/patch/4364341/ -- 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/2] ARM: dts: DRA7: Add node for RTC
On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 02:36]: On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? This feeds on to RTC which is a free running clock. So i guess always on is justified no? Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on. From the PMIC perspective every regulator can be enabled and disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU. I guess RTC also needs the supply to be on as long as we want the clock to be ticking. Also adding temporary dts entries just causes more churn on the dts files which is a PITA for everybody. Regards, Tony 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: gpio-omap: wakeup mask
* Pascal Huerst pascal.hue...@gmail.com [140709 03:18]:
Hey Tony, all
On 04.07.2014 09:27, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140702 05:12]:
Hi everyone,
we have a device with an am335x and are using some gpios on bank0 to
wake up the device from suspend to ram.
We have some user buttons which are configured in the devicetree as
gpio-keys and one power-key which should wake up the device:
buttons {
power {
label = Power;
gpios = gpio0 6 1;
linux,code = 116;
gpio-key,wakeup;
};
one {
label = One;
gpios = gpio0 11 1;
linux,code = 2;
};
: : :
}
The problem is, that the device wakes up on any trigger on bank 0. No
matter which button was pressed. gpio-key,wakeup seems not to have any
influence.
Now, if I comment the following lines out in drivers/gpio/gpio-omap.c :
set_gpio_trigger(...).
321
322 if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
323_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
324 bank-context.wake_en =
325readl_relaxed(bank-base + bank-regs-wkup_en);
326 }
327
Everything works as expected. But I don't really understand why? Is this
a bug, or does this break something else I have not discovered yet?
The GPIO wake-up events are working from off-idle for omap3
the last time I checked, so sounds like this is some am335x
related issue.
Ok, that sounds reasonable.
What does your bank-context.wake_en mask get set to with this code?
by calling 'echo mem /sys/power/state' followed by a wakeup, I get the
following:
[ 28.992866] bank-context-wake_en = 00080040
[ 29.020974] PM: noirq resume of devices complete after 22.439 msecs
I guess that's for gpio bank 0 with no bit 11 as your dts has it
configured. If you just comment out the _gpio_rmw part above do
things work as expected?
Then if that works as expected, maybe write only some unused bits
into wkup_en register and see if it still wakes to all events while
it should not?
It might be worth comparing the GPIO registers between am37xx and
am335x for the wkup_en register.
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 2/2] ARM: dts: DRA7: Add node for RTC
* Keerthy a0393...@ti.com [140709 03:39]: On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 02:36]: On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? This feeds on to RTC which is a free running clock. So i guess always on is justified no? Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on. From the PMIC perspective every regulator can be enabled and disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU. Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that? I guess RTC also needs the supply to be on as long as we want the clock to be ticking. Sure, but if somebody wants shut it off regulator-boot-on is better from driver point of view. 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 2/2] ARM: dts: DRA7: Add node for RTC
On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 03:39]: On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 02:36]: On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? This feeds on to RTC which is a free running clock. So i guess always on is justified no? Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on. From the PMIC perspective every regulator can be enabled and disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU. Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that? regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen. I guess RTC also needs the supply to be on as long as we want the clock to be ticking. Sure, but if somebody wants shut it off regulator-boot-on is better from driver point of view. 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 2/2] ARM: dts: DRA7: Add node for RTC
* Keerthy a0393...@ti.com [140709 03:59]: On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 03:39]: On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 02:36]: On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? This feeds on to RTC which is a free running clock. So i guess always on is justified no? Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on. From the PMIC perspective every regulator can be enabled and disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU. Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that? regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen. That's a bug in the RTC driver then. The driver should request a regulator if it's specified. 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 v3 0/7] ARM: dts: AM43x: Add devcice tree nodes
On Wednesday 09 July 2014 02:01 PM, Tony Lindgren wrote: * Keerthy j-keer...@ti.com [140708 22:40]: 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. Are the .dts changes safe to apply separately without breaking anything? Tony, Patch 1/7 had to be re-based on Mark's latest branch for tps65218. Other patches can be taken as is. These patches are boot tested on both am437x-gp-evm and am43x-epos-evm. Regards, Tony 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 v2] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
On Wednesday 09 July 2014 02:32 PM, Kishon Vijay Abraham I wrote:
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Tested-by: Kishon Vijay Abraham I kis...@ti.com
---
Changes from v1:
* changed the clock domain to pcie_clkdm
* Added PCIe as a slave port for l3_main.
Looks good to me,
Reviewed-by: Rajendra Nayak rna...@ti.com
Boot log for dra7xx can be found at http://paste.ubuntu.com/7769402/
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 73
+
1 file changed, 73 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 6ff40a6..2f37ca8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+ .name = pcie,
+};
+
+/* pcie1 */
+static struct omap_hwmod dra7xx_pcie1_hwmod = {
+ .name = pcie1,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = pcie_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 */
+static struct omap_hwmod dra7xx_pcie2_hwmod = {
+ .name = pcie2,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = pcie_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'PCIE PHY' class
*
*/
@@ -2448,6 +2485,38 @@ static struct omap_hwmod_ocp_if
dra7xx_l4_cfg__ocp2scp1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main_1 - pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pcie1 = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_pcie1_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie1_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 - pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pcie2 = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_pcie2_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie2_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg - pcie1 phy */
static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
.master = dra7xx_l4_cfg_hwmod,
@@ -2813,6 +2882,10 @@ static struct omap_hwmod_ocp_if
*dra7xx_hwmod_ocp_ifs[] __initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l4_cfg__ocp2scp3,
+ dra7xx_l3_main_1__pcie1,
+ dra7xx_l4_cfg__pcie1,
+ dra7xx_l3_main_1__pcie2,
+ dra7xx_l4_cfg__pcie2,
dra7xx_l4_cfg__pcie1_phy,
dra7xx_l4_cfg__pcie2_phy,
dra7xx_l3_main_1__qspi,
--
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/2] ARM: dts: DRA7: Add node for RTC
On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 03:59]: On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 03:39]: On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 02:36]: On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: * Lokesh Vutla lokeshvu...@ti.com [140709 01:37]: --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = 105; regulator-max-microvolt = 105; regulator-boot-on; + regulator-always-on; }; Is this regulator really always on? This feeds on to RTC which is a free running clock. So i guess always on is justified no? Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on. From the PMIC perspective every regulator can be enabled and disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU. Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that? regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen. That's a bug in the RTC driver then. The driver should request a regulator if it's specified. Okay. 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: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
* One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [140707 06:22]: 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. At least for omaps the UARTs need to be idled for the SoC to hit off-idle where the SoC is powered off and rebooted during idle. So we can certainly enable this in a generic way, however, this can only be done under the following conditions: 1. We can save and restore the serial register context and detect when context was lost in the serial driver. The context loss can be detected by looking at some registers that are only initialized during init. 2. There's a way for the serial RX pin to wake the SoC. On some omaps there's a separate pin specific wake-up interrupt that can be used for that. 3. The serial PM features must be only enabled if requested by the user via sysfs. Typically extra latency and loss of the first RX character occur which is not acceptable to most applications. 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: OMAP4: Ctrl module register define diet
* Joachim Eastwood manab...@gmail.com [140521 08:49]: Signed-off-by: Joachim Eastwood manab...@gmail.com --- Hi, The mach-omap2 directory contains full register defines for OMAP4 control module but only around 27 of those are used. There are is a total of 1795 register defines in four files with only 27 in use. That is pretty low usefulness ratio... I guess alot more was used when we had omap4 board files and mach-omap2 contained more drivers but this has now changed. So I propose we move just what we need to control.h, were other OMAP parts have their minimal set of defines already. Patch has been compile tested and I have also grepped the tree for users outside the mach dir. Yeah great, applying this into omap-for-v3.17/soc finally. 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: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
On 07/09/2014 01:17 PM, Tony Lindgren wrote: * One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [140707 06:22]: 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. At least for omaps the UARTs need to be idled for the SoC to hit off-idle where the SoC is powered off and rebooted during idle. So we can certainly enable this in a generic way, however, this can only be done under the following conditions: 1. We can save and restore the serial register context and detect when context was lost in the serial driver. The context loss can be detected by looking at some registers that are only initialized during init. A register check on restore context? DLL+DLH might be a good hint here since its value should be 0 in the running case. 2. There's a way for the serial RX pin to wake the SoC. On some omaps there's a separate pin specific wake-up interrupt that can be used for that. That one would be handled by omap separately. 3. The serial PM features must be only enabled if requested by the user via sysfs. Typically extra latency and loss of the first RX character occur which is not acceptable to most applications. Unless I'm mistaken the omap driver now initializes the timeout to -1. So nothing happens unless this is enabled separately. Regards, Tony Sebastian -- 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] omap: Add devicetree for Gumstix Pepper board
* Ash Charles ashchar...@gmail.com [140610 15:24]: This adds the Gumstix Pepper[1] single-board computer based on the TI AM335x processor. Schematics are available [2]. [1] https://store.gumstix.com/index.php/products/344/ [2] https://pubs.gumstix.com/boards/PEPPER/ Applying into omap-for-v3.17/dt thanks. 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] ASoC: omap-hdmi: Use devm_snd_soc_register_component
Hi Peter, On Wed, Jul 9, 2014 at 11:18 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: 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. Ok fine. Thanks 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: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
* Sebastian Andrzej Siewior bige...@linutronix.de [140709 04:38]: On 07/09/2014 01:17 PM, Tony Lindgren wrote: * One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [140707 06:22]: 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. At least for omaps the UARTs need to be idled for the SoC to hit off-idle where the SoC is powered off and rebooted during idle. So we can certainly enable this in a generic way, however, this can only be done under the following conditions: Sorry forgot to mention why I think this can now be done in a generic way, that's because we have now runtime PM in Linux. 1. We can save and restore the serial register context and detect when context was lost in the serial driver. The context loss can be detected by looking at some registers that are only initialized during init. A register check on restore context? DLL+DLH might be a good hint here since its value should be 0 in the running case. OK yeah that would be a generic way to do it potentially ;) Note that all the context_loss_cnt stuff in omap-serial.c can then be ignored, that's still only needed for the omap3 legacy mode booting case and won't be needed much longer. 2. There's a way for the serial RX pin to wake the SoC. On some omaps there's a separate pin specific wake-up interrupt that can be used for that. That one would be handled by omap separately. OK great. 3. The serial PM features must be only enabled if requested by the user via sysfs. Typically extra latency and loss of the first RX character occur which is not acceptable to most applications. Unless I'm mistaken the omap driver now initializes the timeout to -1. So nothing happens unless this is enabled separately. Yes that's the only safe approach so the serial port behaves in the standard Linux way unless specifically requested by the user. 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 v3 0/7] ARM: dts: AM43x: Add devcice tree nodes
* Keerthy a0393...@ti.com [140709 04:03]: On Wednesday 09 July 2014 02:01 PM, Tony Lindgren wrote: * Keerthy j-keer...@ti.com [140708 22:40]: 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. Are the .dts changes safe to apply separately without breaking anything? Tony, Patch 1/7 had to be re-based on Mark's latest branch for tps65218. Other patches can be taken as is. These patches are boot tested on both am437x-gp-evm and am43x-epos-evm. OK thanks applying patches 4 - 7 into omap-for-v3.17/dt. 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 3/3] ARM: dts: dra7-evm: Add regulator information to USB2 PHYs
* Roger Quadros rog...@ti.com [140630 04:02]: The ldousb_reg regulator provides power to the USB1 and USB2 High Speed PHYs. Applying this one into omap-for-v3.17/dt 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
[PATCH RESEND] ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated struct platform_device
gpmc_nand_device it is not possible to configure the system to
use more than one NAND device connected to the GPMC. This
modification makes it possible to use up to 8 NAND devices
connected to the GPMC controller.
Signed-off-by: Rostislav Lisovy lis...@merica.cz
---
Tested on custom AM335x board with two different NAND chips
(128 + 256 MiB) using GPMC configuration in FDT -- behaves
correctly.
arch/arm/mach-omap2/gpmc-nand.c | 79 +++--
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 4349e82..c5481a8 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -24,25 +24,6 @@
/* minimum size for IO mapping */
#defineNAND_IO_SIZE4
-static struct resource gpmc_nand_resource[] = {
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .flags = IORESOURCE_IRQ,
- },
- {
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device gpmc_nand_device = {
- .name = omap2-nand,
- .id = 0,
- .num_resources = ARRAY_SIZE(gpmc_nand_resource),
- .resource = gpmc_nand_resource,
-};
-
static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* platforms which support all ECC schemes */
@@ -93,43 +74,41 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
{
int err = 0;
struct gpmc_settings s;
- struct device *dev = gpmc_nand_device.dev;
-
- memset(s, 0, sizeof(struct gpmc_settings));
+ struct platform_device *pdev;
+ struct resource gpmc_nand_res[] = {
+ { .flags = IORESOURCE_MEM, },
+ { .flags = IORESOURCE_IRQ, },
+ { .flags = IORESOURCE_IRQ, },
+ };
- gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+ BUG_ON(gpmc_nand_data-cs = GPMC_CS_NUM);
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
- (unsigned long *)gpmc_nand_resource[0].start);
+ (unsigned long *)gpmc_nand_res[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS %d, error %d\n,
- gpmc_nand_data-cs, err);
+ pr_err(omap2-gpmc: Cannot request GPMC CS %d, error %d\n,
+ gpmc_nand_data-cs, err);
return err;
}
-
- gpmc_nand_resource[0].end = gpmc_nand_resource[0].start +
- NAND_IO_SIZE - 1;
-
- gpmc_nand_resource[1].start =
- gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
- gpmc_nand_resource[2].start =
- gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+ gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
+ gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
+ gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
if (gpmc_t) {
err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
if (err 0) {
- dev_err(dev, Unable to set gpmc timings: %d\n, err);
+ pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
return err;
}
}
+ memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
else
gpmc_set_legacy(gpmc_nand_data, s);
s.device_nand = true;
-
err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
if (err 0)
goto out_free_cs;
@@ -141,18 +120,34 @@ 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)) {
- dev_err(dev, Unsupported NAND ECC scheme selected\n);
- return -EINVAL;
+ pr_err(omap2-nand: Unsupported NAND ECC scheme selected\n);
+ err = -EINVAL;
+ goto out_free_cs;
}
- err = platform_device_register(gpmc_nand_device);
- if (err 0) {
- dev_err(dev, Unable to register NAND device\n);
- goto out_free_cs;
+
+ pdev = platform_device_alloc(omap2-nand, gpmc_nand_data-cs);
+ if (pdev) {
+ err = platform_device_add_resources(pdev, gpmc_nand_res,
+ ARRAY_SIZE(gpmc_nand_res));
+ if (!err)
+ pdev-dev.platform_data = gpmc_nand_data;
+ } else {
+
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Wednesday 09 July 2014 02:55 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140708 01:32]:
* 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?
I guess no more comments. Took a look at the patch again, Sekhar, can
you please update the description with what has been discovered in this
thread and repost?
How does the following sound:
---
AM437x has L2C-310 version r3p2 and ROM code on that device 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.
From the public TRM available for OMAP4470, even on that device, ROM
does not support writing to this register even though it uses a version
of L2C-310 which has the register implemented. So this patch should take
care of all variants of existing OMAPs.
---
Two things that I have added are the version of L2C on AM437x and the
fact that OMAP4470 also has the same issue (at least from the public
TRM). Let me know if you would like to see anything else mentioned.
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] ARM: OMAP2+: l2c: squelch warning dump on power control setting
* Sekhar Nori nsek...@ti.com [140709 05:28]:
On Wednesday 09 July 2014 02:55 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140708 01:32]:
* 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?
I guess no more comments. Took a look at the patch again, Sekhar, can
you please update the description with what has been discovered in this
thread and repost?
How does the following sound:
---
AM437x has L2C-310 version r3p2 and ROM code on that device 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.
From the public TRM available for OMAP4470, even on that device, ROM
does not support writing to this register even though it uses a version
of L2C-310 which has the register implemented. So this patch should take
care of all variants of existing OMAPs.
---
Two things that I have added are the version of L2C on AM437x and the
fact that OMAP4470 also has the same issue (at least from the public
TRM). Let me know if you would like to see anything else mentioned.
Looks good to me 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
[RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
Hi, The following hardware modules/registers are meant for NAND controller driver usage: - NAND I/O control (NAND address, data, command registers) - Prefetch/Write-post engine - ECC/BCH engine However, these registers sit in the GPMC controller's register space and there need to be some sane way to access them from the OMAP NAND controller driver. Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs) with the register addresses and passing it to the OMAP NAND driver via platform data. This mechanism cannot be used for true Device tree support as custom platform data passing mechanism doesn't seem to work. Moreover, direct access to these registers must be limited to the GPMC driver. This calls for a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use to access these GPMC space registers. This series attempts to add the following new APIs and gets rid of 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'. -For NAND I/O control registers u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg); void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val); -For Prefetch engine int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma, u32 count, int is_write); int omap_gpmc_prefetch_stop(int cs); u32 omap_gpmc_get_prefetch_count(void); u32 omap_gpmc_get_prefetch_fifo_count(void); -For ECC/BCH engine void omap_gpmc_ecc_disable(void); void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0, u8 ecc_size1, bool use_bch, enum omap_gpmc_bch_type bch_type, u8 bch_sectors, u8 bch_wrap_mode); void omap_gpmc_ecc_get_result(int length, u32 *result); void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result); These APIs don't implement any logic to serialize access to the NAND/Prefetch/ECC registers. It is upto the NAND controller driver to ensure that. As these modules can only handle one NAND controller context at a time, we set the nand_chip-hwcontrol to point to a single controller instance even if there are multiple NAND chips on different Chip select spaces. The NAND base driver then takes care of serializing access to the NAND controller (and ECC) through nandchip-hwcontrol-lock. NOTE: Patches are still untested and only meant for review. cheers, -roger --- Roger Quadros (10): mtd: nand: omap: Use a single hardware controller instance mtd: nand: omap: Always use chip-ecc.steps for BCH sector count OMAP: GPMC: Introduce APIs to access NAND control registers mtd: nand: omap: Use GPMC APIs for NAND control OMAP: GPMC: Introduce APIs for accessing Prefetch/Write-post engine mtd: nand: omap: Use GPMC APIs for accessing Prefetch engine OMAP: GPMC: Introduce APIs for Configuring ECC Engine OMAP: GPMC: Introduce APIs to get ECC/BCH results mtd: nand: omap: Use GPMC APIs for accessing ECC/BCH engine OMAP: GPMC: NAND: Don't pass NAND/ECC/BCH register adresses to NAND driver arch/arm/mach-omap2/gpmc-nand.c | 2 - arch/arm/mach-omap2/gpmc.c | 464 +++ arch/arm/mach-omap2/gpmc.h | 1 - drivers/mtd/nand/omap2.c | 397 +-- include/linux/omap-gpmc-nand.h | 106 ++ include/linux/platform_data/mtd-nand-omap2.h | 5 +- 6 files changed, 663 insertions(+), 312 deletions(-) create mode 100644 include/linux/omap-gpmc-nand.h -- 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
[RFC PATCH 05/10] OMAP: GPMC: Introduce APIs for accessing Prefetch/Write-post engine
Even though the Prefetch engine is meant for exclusive use by
the OMAP NAND controller, itst registers belong to the GPMC controller's
register space.
Introduce 4 APIs to access the Prefetch/Write-post engine.
int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma,
u32 count, int is_write);
int omap_gpmc_prefetch_stop(int cs);
u32 omap_gpmc_get_prefetch_count(void);
u32 omap_gpmc_get_prefetch_fifo_count(void);
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 134 +
include/linux/omap-gpmc-nand.h | 30 +
2 files changed, 164 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 92bbada..43e2a9d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -33,6 +33,7 @@
#include linux/pm_runtime.h
#include linux/omap-gpmc-nand.h
#include linux/platform_data/mtd-nand-omap2.h
+#include linux/bitops.h
#include asm/mach-types.h
@@ -114,6 +115,20 @@
#define GPMC_NR_WAITPINS 4
+/* GPMC Prefetch/Write-post Engine */
+#define GPMC_PREFETCH_CONFIG1_ENABLE_PREFETCH BIT(7)
+#define GPMC_PREFETCH_CONFIG1_DMAMODE BIT(2)
+#define GPMC_PREFETCH_CONFIG1_ACCESSMODE BIT(0)
+#define GPMC_PREFETCH_CONFIG1_CS_MASK GENMASK(26, 24)
+#define GPMC_PREFETCH_CONFIG1_CS_SHIFT 24
+#define GPMC_PREFETCH_CONFIG1_FIFOTH_MASK GENMASK(14, 8)
+#define GPMC_PREFETCH_CONFIG1_FIFOTH_SHIFT 8
+
+#define GPMC_PREFETCH_CONTROL_STARTBIT(0)
+
+#define GPMC_PREFETCH_STATUS_COUNT(val)(val 0x3fff)
+#define GPMC_PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#defineGPMC_NR_IRQ 2
@@ -1971,3 +1986,122 @@ void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg
reg, u32 val)
break;
}
}
+
+/**
+ * omap_gpmc_prefetch_start - configures and starts the prefetch engine
+ *
+ * @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @dma: dma mode enable (1) or disable (0)
+ * @count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ *
+ * As there is a single prefetch engine that must be shared between
+ * chip selects containing NAND flashes, the function returns -EBUSY if
+ * the engine is already in use. Returns 0 on success.
+ */
+int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma,
+u32 count, int is_write)
+{
+ u32 val;
+
+ if (!gpmc_dev)
+ return -ENODEV;
+
+ if (cs = gpmc_cs_num)
+ return -EINVAL;
+
+ if (fifo_th GPMC_PREFETCH_FIFOTHRESHOLD_MAX)
+ return -EINVAL;
+
+ /* Check if engine is already in use */
+ if (gpmc_read_reg(GPMC_PREFETCH_CONTROL))
+ return -EBUSY;
+
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, count);
+
+ /* Set dma/mpu mode, the prefetch read / post write and
+* enable the engine. Set which cs is has requested for.
+*/
+ val = ((cs GPMC_PREFETCH_CONFIG1_CS_SHIFT) |
+ GPMC_PREFETCH_CONFIG1_ENABLE_PREFETCH |
+ (GPMC_PREFETCH_CONFIG1_ACCESSMODE is_write));
+
+ val |= (fifo_th GPMC_PREFETCH_CONFIG1_FIFOTH_SHIFT)
+ GPMC_PREFETCH_CONFIG1_FIFOTH_MASK;
+
+ if (dma)
+ val |= GPMC_PREFETCH_CONFIG1_DMAMODE;
+
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, val);
+
+ /* Start the prefetch engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, GPMC_PREFETCH_CONTROL_START);
+
+ return 0;
+}
+
+/**
+ * omap_gpmc_prefetch_stop - stops and disables the prefetch engine
+ *
+ * @cs: Chip select number
+ */
+int omap_gpmc_prefetch_stop(int cs)
+{
+ u32 config1;
+
+ if (!gpmc_dev)
+ return -ENODEV;
+
+ if (cs = gpmc_cs_num)
+ return -EINVAL;
+
+ /* check if the same module/cs is trying to reset */
+ config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ config1 = GPMC_PREFETCH_CONFIG1_CS_MASK;
+
+ if ((config1 GPMC_PREFETCH_CONFIG1_CS_SHIFT) != cs)
+ return -EINVAL;
+
+ /* Stop the engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0);
+
+ /* Reset/disable the engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0);
+
+ return 0;
+}
+
+/**
+ * omap_gpmc_get_prefetch_count - Returns the number of bytes remaining to be
+ * read or written by the prefetch/write-post engine
+ */
+u32 omap_gpmc_get_prefetch_count(void)
+{
+ u32 count;
+
+ if (!gpmc_dev)
+ return 0;
+
+ count = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ count = GPMC_PREFETCH_STATUS_COUNT(count);
+ return count;
+}
+
+/**
+ * omap_gpmc_get_prefetch_fifo_count - Returns the number of bytes
[RFC PATCH 08/10] OMAP: GPMC: Introduce APIs to get ECC/BCH results
Even though the ECC/BCH engine is meant for exclusive use by
the OMAP NAND controller, the ECC/BCH result registers belong
to the GPMC controller's register space.
Introduce 2 APIs to access the ECC/BCH results.
void omap_gpmc_ecc_get_result(int length, u32 *result);
void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result);
The first one is to get the Hamming code ECC result registers
and the second one is to get the BCH ECC result registers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 97 +++---
include/linux/omap-gpmc-nand.h | 11 +
2 files changed, 101 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8befd16..944 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -65,6 +65,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC9_RESULT0x220
#define GPMC_ECC_BCH_RESULT_0 0x240 /* not available on OMAP2 */
#defineGPMC_ECC_BCH_RESULT_1 0x244 /* not available on OMAP2 */
#defineGPMC_ECC_BCH_RESULT_2 0x248 /* not available on OMAP2 */
@@ -83,6 +84,7 @@
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
#defineGPMC_BCH_SIZE 0x10
+#define GPMC_BCH_NUM 7 /* Max no. of BCH registers 0-6 */
#define GPMC_MEM_END 0x3FFF
@@ -96,9 +98,10 @@
#defineGPMC_REVISION_MAJOR(l) ((l 4) 0xf)
#defineGPMC_REVISION_MINOR(l) (l 0xf)
-#defineGPMC_HAS_WR_ACCESS 0x1
-#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
-#defineGPMC_HAS_MUX_AAD0x4
+#defineGPMC_HAS_WR_ACCESS BIT(0)
+#defineGPMC_HAS_WR_DATA_MUX_BUSBIT(1)
+#defineGPMC_HAS_MUX_AADBIT(2)
+#defineGPMC_HAS_BCHBIT(3)
#define GPMC_NR_WAITPINS 4
@@ -185,6 +188,7 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map = ((1 GPMC_CS_NUM) - 1);
static unsigned int gpmc_cs_num = GPMC_CS_NUM;
static unsigned int gpmc_nr_waitpins;
+static unsigned int gpmc_bch_num = GPMC_BCH_NUM;
static struct device *gpmc_dev;
static int gpmc_irq;
static resource_size_t phys_base, mem_size;
@@ -198,6 +202,7 @@ struct gpmc_nand_reg {
};
static struct gpmc_nand_reg gpmc_nand_reg_map[GPMC_CS_NUM];
+void __iomem *gpmc_bch_reg_map[GPMC_BCH_NUM][GPMC_BCH_NUM_REMAINDER];
static struct clk *gpmc_l3_clk;
@@ -205,7 +210,7 @@ static irqreturn_t gpmc_handle_irq(int irq, void *dev);
static void gpmc_fill_nand_reg_map(void)
{
- int i;
+ int i, j;
for (i = 0; i gpmc_cs_num; i++) {
gpmc_nand_reg_map[i].command = gpmc_base + GPMC_CS0_OFFSET +
@@ -215,6 +220,28 @@ static void gpmc_fill_nand_reg_map(void)
gpmc_nand_reg_map[i].data = gpmc_base + GPMC_CS0_OFFSET +
GPMC_CS_NAND_DATA + GPMC_CS_SIZE * i;
}
+
+ if (!(gpmc_capability GPMC_HAS_BCH))
+ return;
+
+
+ for (i = 0; i 4; i++) {
+ for (j = 0; j 8; j++) {
+ gpmc_bch_reg_map[i][j] = gpmc_base +
+GPMC_ECC_BCH_RESULT_0 +
+i * 4 + GPMC_BCH_SIZE * j;
+ }
+ }
+
+ /* 2nd for loop for BCH4 onwards due to non-consecutive address */
+ for (i = 4; i gpmc_bch_num; i++) {
+ for (j = 0; j 8; j++) {
+ gpmc_bch_reg_map[i][j] = gpmc_base +
+GPMC_ECC_BCH_RESULT_4 +
+(i - 4) * 4 +
+GPMC_BCH_SIZE * j;
+ }
+ }
}
static void gpmc_write_reg(int idx, u32 val)
@@ -1738,10 +1765,17 @@ static int gpmc_probe(struct platform_device *pdev)
* - OMAP3xxx = 5.0
* - OMAP44xx/54xx/AM335x = 6.0
*/
- if (GPMC_REVISION_MAJOR(l) 0x4)
- gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;
- if (GPMC_REVISION_MAJOR(l) 0x5)
+ if (GPMC_REVISION_MAJOR(l) = 5) {
+ gpmc_capability = GPMC_HAS_WR_ACCESS |
+ GPMC_HAS_WR_DATA_MUX_BUS | GPMC_HAS_BCH;
+ gpmc_bch_num = 4;
+ }
+
+ if (GPMC_REVISION_MAJOR(l) = 6) {
gpmc_capability |= GPMC_HAS_MUX_AAD;
+ gpmc_bch_num = GPMC_BCH_NUM;
+ }
+
dev_info(gpmc_dev, GPMC revision %d.%d\n, GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
@@ -2188,3 +,52 @@ void omap_gpmc_ecc_configure_enable(int cs, bool ecc16,
u8 ecc_size0,
val |=
[RFC PATCH 09/10] mtd: nand: omap: Use GPMC APIs for accessing ECC/BCH engine
Don't access the ECC/BCH engine registers directly as they belong
to the GPMC controller's register space. Use the relevant
GPMC APIs instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 191 +++
1 file changed, 76 insertions(+), 115 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 420ef0b..6b0f953 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -865,16 +865,10 @@ static int omap_correct_data(struct mtd_info *mtd, u_char
*dat,
static int omap_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
u_char *ecc_code)
{
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
u32 val;
- val = readl(info-reg.gpmc_ecc_config);
- if (((val ECC_CONFIG_CS_SHIFT) ~CS_MASK) != info-gpmc_cs)
- return -EINVAL;
-
/* read ecc result */
- val = readl(info-reg.gpmc_ecc1_result);
+ omap_gpmc_ecc_get_result(1, val);
*ecc_code++ = val; /* P128e, ..., P1e */
*ecc_code++ = val 16;/* P128o, ..., P1o */
/* P2048o, P1024o, P512o, P256o, P2048e, P1024e, P512e, P256e */
@@ -894,34 +888,22 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
mtd);
struct nand_chip *chip = mtd-priv;
unsigned int dev_width = (chip-options NAND_BUSWIDTH_16) ? 1 : 0;
- u32 val;
-
- /* clear ecc and enable bits */
- val = ECCCLEAR | ECC1;
- writel(val, info-reg.gpmc_ecc_control);
+ u32 ecc_size0;
- /* program ecc and result sizes */
- val = info-nand.ecc.size 1) - 1) ECCSIZE1_SHIFT) |
-ECC1RESULTSIZE);
- writel(val, info-reg.gpmc_ecc_size_config);
+ ecc_size0 = (info-nand.ecc.size 1) - 1;
switch (mode) {
case NAND_ECC_READ:
case NAND_ECC_WRITE:
- writel(ECCCLEAR | ECC1, info-reg.gpmc_ecc_control);
+ omap_gpmc_ecc_configure_enable(info-gpmc_cs, dev_width,
+ ecc_size0, 0, false,
+ 0, 0, 0);
break;
case NAND_ECC_READSYN:
- writel(ECCCLEAR, info-reg.gpmc_ecc_control);
- break;
- default:
- dev_info(info-pdev-dev,
- error: unrecognized Mode[%d]!\n, mode);
+ /* Disable the engine, but don't clear ECC results */
+ omap_gpmc_ecc_disable();
break;
}
-
- /* (ECC 16 or 8 bit col) | ( CS ) | ECC Enable */
- val = (dev_width 7) | (info-gpmc_cs 1) | (0x1);
- writel(val, info-reg.gpmc_ecc_config);
}
/**
@@ -993,20 +975,20 @@ static int omap_dev_ready(struct mtd_info *mtd)
*/
static void __maybe_unused omap_enable_hwecc_bch(struct mtd_info *mtd, int
mode)
{
- unsigned int bch_type;
+ enum omap_gpmc_bch_type bch_type;
unsigned int dev_width, nsectors;
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
enum omap_ecc ecc_opt = info-ecc_opt;
struct nand_chip *chip = mtd-priv;
- u32 val, wr_mode;
+ u32 wr_mode;
unsigned int ecc_size1, ecc_size0;
/* GPMC configurations for calculating ECC */
nsectors = chip-ecc.steps;
switch (ecc_opt) {
case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
- bch_type = 0;
+ bch_type = OMAP_GPMC_BCH4;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1018,7 +1000,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
}
break;
case OMAP_ECC_BCH4_CODE_HW:
- bch_type = 0;
+ bch_type = OMAP_GPMC_BCH4;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH4R_ECC_SIZE0;
@@ -1030,7 +1012,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
}
break;
case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
- bch_type = 1;
+ bch_type = OMAP_GPMC_BCH8;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1042,7 +1024,7 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
}
break;
case OMAP_ECC_BCH8_CODE_HW:
- bch_type = 1;
+ bch_type = OMAP_GPMC_BCH8;
if (mode ==
[RFC PATCH 07/10] OMAP: GPMC: Introduce APIs for Configuring ECC Engine
Even though the ECC/BCH engine is meant for exclusive use by
the OMAP NAND controller, the ECC/BCH registers belong
to the GPMC controller's register space
Add omap_gpmc_ecc_configure_enable() and omap_gpmc_ecc_disable()
to manage the ECC engine. OMAP NAND driver must use these APIs
instead of directly accessing the ECC Engine registers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 109 -
include/linux/omap-gpmc-nand.h | 25 ++
2 files changed, 121 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 43e2a9d..8befd16 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -73,19 +73,6 @@
#defineGPMC_ECC_BCH_RESULT_5 0x304 /* not available on OMAP2 */
#defineGPMC_ECC_BCH_RESULT_6 0x308 /* not available on OMAP2 */
-/* GPMC ECC control settings */
-#define GPMC_ECC_CTRL_ECCCLEAR 0x100
-#define GPMC_ECC_CTRL_ECCDISABLE 0x000
-#define GPMC_ECC_CTRL_ECCREG1 0x001
-#define GPMC_ECC_CTRL_ECCREG2 0x002
-#define GPMC_ECC_CTRL_ECCREG3 0x003
-#define GPMC_ECC_CTRL_ECCREG4 0x004
-#define GPMC_ECC_CTRL_ECCREG5 0x005
-#define GPMC_ECC_CTRL_ECCREG6 0x006
-#define GPMC_ECC_CTRL_ECCREG7 0x007
-#define GPMC_ECC_CTRL_ECCREG8 0x008
-#define GPMC_ECC_CTRL_ECCREG9 0x009
-
#defineGPMC_CONFIG2_CSEXTRADELAY BIT(7)
#defineGPMC_CONFIG3_ADVEXTRADELAY BIT(7)
#defineGPMC_CONFIG4_OEEXTRADELAY BIT(7)
@@ -129,6 +116,28 @@
#define GPMC_PREFETCH_STATUS_COUNT(val)(val 0x3fff)
#define GPMC_PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
+/* GPMC ECC config */
+#define GPMC_ECC_CONFIG_ECCENABLE BIT(0)
+#define GPMC_ECC_CONFIG_ECCCS_MASK GENMASK(3, 1)
+#define GPMC_ECC_CONFIG_ECCCS_SHIFT1
+#define GPMC_ECC_CONFIG_ECCNSECTOR_MASKGENMASK(6, 4)
+#define GPMC_ECC_CONFIG_ECCNSECTOR_SHIFT 4
+#define GPMC_ECC_CONFIG_ECC16B BIT(7)
+#define GPMC_ECC_CONFIG_ECCWRAPMODE_MASK GENMASK(11, 8)
+#define GPMC_ECC_CONFIG_ECCWRAPMODE_SHIFT 8
+#define GPMC_ECC_CONFIG_ECCBCHTSEL_MASKGENMASK(13, 12)
+#define GPMC_ECC_CONFIG_ECCBCHTSEL_SHIFT 12
+#define GPMC_ECC_CONFIG_ECCALGBCH BIT(16)
+
+/* GPMC ECC control */
+#defineGPMC_ECC_CONTROL_ECCCLEAR BIT(8)
+#define GPMC_ECC_CONTROL_ECCPOINTER_MASK GENMASK(3, 0)
+#define GPMC_ECC_CONTROL_ECCPOINTER_SHIFT 0
+
+/* GPMC ECC size */
+#define GPMC_ECC_SIZE_ECCSIZE0_SHIFT 12
+#define GPMC_ECC_SIZE_ECCSIZE1_SHIFT 22
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#defineGPMC_NR_IRQ 2
@@ -2105,3 +2114,77 @@ u32 omap_gpmc_get_prefetch_fifo_count(void)
count = GPMC_PREFETCH_STATUS_FIFO_CNT(count);
return count;
}
+
+/**
+ * omap_gpmc_ecc_disable - Disables the ECC engine
+ * but doesn't clear the ECC result registers.
+ */
+void omap_gpmc_ecc_disable(void)
+{
+ u32 val;
+
+ /* Disable ECC engine if running */
+ val = gpmc_read_reg(GPMC_ECC_CONFIG);
+ if (val GPMC_ECC_CONFIG_ECCENABLE) {
+ val = ~GPMC_ECC_CONFIG_ECCENABLE;
+ gpmc_write_reg(GPMC_ECC_CONFIG, val);
+ }
+}
+
+/**
+ * omap_gpmc_ecc_configure_enable - Configures and enables the ECC-BCH engine
+ *
+ * @cs: chip select number
+ * @ecc16: true for 16-bit ECC column, false for 8-bit ECC columna
+ * @ecc_size0: This value is written to ECCSIZE0 of GPMC_ECC_SIZE_CONFIG reg.
+ * @ecc_size1: This value is written to ECCSIZE1 of GPMC_ECC_SIZE_CONFIG reg.
+ * @use_bch: true for BCH algorithm, false for 1-bit Hamming code algorithm
+ * @bch_type: enum omap_gpmc_bch_type, 4-bit, 8-bit or 16-bit BCH error
+ * correction cabability. Ignored if use_bch is false.
+ * @bch_sectors: No. of sectors to process with BCH. Ignored if use_bch false.
+ * @bch_wrap_mode: pre defined spare area defination for BCH calculation.
+ *Ignored if use_bch is false
+ */
+void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0,
+ u8 ecc_size1, bool use_bch,
+ enum omap_gpmc_bch_type bch_type,
+ u8 bch_sectors, u8 bch_wrap_mode)
+{
+ u32 val, valx;
+
+ /* Disable ECC engine if running */
+ omap_gpmc_ecc_disable();
+
+ /* Clear all ECC/BCH result registers */
+ gpmc_write_reg(GPMC_ECC_CONTROL, GPMC_ECC_CONTROL_ECCCLEAR);
+
+ /* ECC size */
+ val = (ecc_size1 GPMC_ECC_SIZE_ECCSIZE1_SHIFT) |
+ (ecc_size0 GPMC_ECC_SIZE_ECCSIZE0_SHIFT);
+ gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, val);
+
+ /* ECC config */
+ val = (cs
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Wed, Jul 09, 2014 at 05:56:37PM +0530, Sekhar Nori wrote: On Wednesday 09 July 2014 02:55 PM, Tony Lindgren wrote: I guess no more comments. Took a look at the patch again, Sekhar, can you please update the description with what has been discovered in this thread and repost? How does the following sound: --- AM437x has L2C-310 version r3p2 and ROM code on that device 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. From the public TRM available for OMAP4470, even on that device, ROM does not support writing to this register even though it uses a version of L2C-310 which has the register implemented. So this patch should take care of all variants of existing OMAPs. --- That sounds perfect, and explains why the change has to exist, and why it can't be fixed elsewhere. Thanks for providing the full reasoning in the commit message. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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
[RFC PATCH 06/10] mtd: nand: omap: Use GPMC APIs for accessing Prefetch engine
Don't access the Prefetch engine registers directly as they belong
to the GPMC controller's register space. Use the relevant GPMC
APIs instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 155 ++-
1 file changed, 45 insertions(+), 110 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f50e71d..420ef0b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -100,20 +100,13 @@
#define P4e_s(a) (TF(a NAND_Ecc_P4e)0)
#define P4o_s(a) (TF(a NAND_Ecc_P4o)1)
-#definePREFETCH_CONFIG1_CS_SHIFT 24
#defineECC_CONFIG_CS_SHIFT 1
#defineCS_MASK 0x7
-#defineENABLE_PREFETCH (0x1 7)
-#defineDMA_MPU_MODE_SHIFT 2
#defineECCSIZE0_SHIFT 12
#defineECCSIZE1_SHIFT 22
#defineECC1RESULTSIZE 0x1
#defineECCCLEAR0x100
#defineECC10x1
-#definePREFETCH_FIFOTHRESHOLD_MAX 0x40
-#definePREFETCH_FIFOTHRESHOLD(val) ((val) 8)
-#definePREFETCH_STATUS_COUNT(val) (val 0x3fff)
-#definePREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
#defineSTATUS_BUFF_EMPTY 0x0001
#define OMAP24XX_DMA_GPMC 4
@@ -177,63 +170,6 @@ struct omap_nand_info {
};
/**
- * omap_prefetch_enable - configures and starts prefetch transfer
- * @cs: cs (chip select) number
- * @fifo_th: fifo threshold to be used for read/ write
- * @dma_mode: dma mode enable (1) or disable (0)
- * @u32_count: number of bytes to be transferred
- * @is_write: prefetch read(0) or write post(1) mode
- */
-static int omap_prefetch_enable(int cs, int fifo_th, int dma_mode,
- unsigned int u32_count, int is_write, struct omap_nand_info *info)
-{
- u32 val;
-
- if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX)
- return -1;
-
- if (readl(info-reg.gpmc_prefetch_control))
- return -EBUSY;
-
- /* Set the amount of bytes to be prefetched */
- writel(u32_count, info-reg.gpmc_prefetch_config2);
-
- /* Set dma/mpu mode, the prefetch read / post write and
-* enable the engine. Set which cs is has requested for.
-*/
- val = ((cs PREFETCH_CONFIG1_CS_SHIFT) |
- PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH |
- (dma_mode DMA_MPU_MODE_SHIFT) | (0x1 is_write));
- writel(val, info-reg.gpmc_prefetch_config1);
-
- /* Start the prefetch engine */
- writel(0x1, info-reg.gpmc_prefetch_control);
-
- return 0;
-}
-
-/**
- * omap_prefetch_reset - disables and stops the prefetch engine
- */
-static int omap_prefetch_reset(int cs, struct omap_nand_info *info)
-{
- u32 config1;
-
- /* check if the same module/cs is trying to reset */
- config1 = readl(info-reg.gpmc_prefetch_config1);
- if (((config1 PREFETCH_CONFIG1_CS_SHIFT) CS_MASK) != cs)
- return -EINVAL;
-
- /* Stop the PFPW engine */
- writel(0x0, info-reg.gpmc_prefetch_control);
-
- /* Reset/disable the PFPW engine */
- writel(0x0, info-reg.gpmc_prefetch_config1);
-
- return 0;
-}
-
-/**
* omap_hwcontrol - hardware specific access to control-lines
* @mtd: MTD device structure
* @cmd: command to device
@@ -362,26 +298,26 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
len -= len % 4;
}
- /* configure and start prefetch transfer */
- ret = omap_prefetch_enable(info-gpmc_cs,
- PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0, info);
+ /* configure and start prefetch engine */
+ ret = omap_gpmc_prefetch_start(info-gpmc_cs,
+ GPMC_PREFETCH_FIFOTHRESHOLD_MAX,
+ false, len, false);
if (ret) {
- /* PFPW engine is busy, use cpu copy method */
+ /* prefetch engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
omap_read_buf16(mtd, (u_char *)p, len);
else
omap_read_buf8(mtd, (u_char *)p, len);
} else {
do {
- r_count = readl(info-reg.gpmc_prefetch_status);
- r_count = PREFETCH_STATUS_FIFO_CNT(r_count);
+ r_count = omap_gpmc_get_prefetch_fifo_count();
r_count = r_count 2;
ioread32_rep(info-nand.IO_ADDR_R, p, r_count);
p += r_count;
len -= r_count 2;
} while (len);
- /* disable and stop the PFPW engine */
-
[RFC PATCH 04/10] mtd: nand: omap: Use GPMC APIs for NAND control
Use the omap_gpmc_read_reg() and omap_gpmc_write_reg() APIs to
access the GPMC_STATUS, NAND_COMMAND, NAND_ADDRESS and NAND_DATA
registers from the GPMC register space.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 6f3d7cd..f50e71d 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -24,7 +24,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/of_device.h
-
+#include linux/omap-gpmc-nand.h
#include linux/mtd/nand_bch.h
#include linux/platform_data/elm.h
@@ -251,13 +251,16 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
if (cmd != NAND_CMD_NONE) {
if (ctrl NAND_CLE)
- writeb(cmd, info-reg.gpmc_nand_command);
+ omap_gpmc_write_reg(info-gpmc_cs,
+ OMAP_GPMC_NAND_COMMAND, cmd);
else if (ctrl NAND_ALE)
- writeb(cmd, info-reg.gpmc_nand_address);
+ omap_gpmc_write_reg(info-gpmc_cs,
+ OMAP_GPMC_NAND_ADDRESS, cmd);
else /* NAND_NCE */
- writeb(cmd, info-reg.gpmc_nand_data);
+ omap_gpmc_write_reg(info-gpmc_cs,
+ OMAP_GPMC_NAND_DATA, cmd);
}
}
@@ -291,7 +294,7 @@ static void omap_write_buf8(struct mtd_info *mtd, const
u_char *buf, int len)
iowrite8(*p++, info-nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
- status = readl(info-reg.gpmc_status)
+ status = omap_gpmc_read_reg(0, OMAP_GPMC_STATUS)
STATUS_BUFF_EMPTY;
} while (!status);
}
@@ -329,7 +332,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const
u_char * buf, int len)
iowrite16(*p++, info-nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
- status = readl(info-reg.gpmc_status)
+ status = omap_gpmc_read_reg(0, OMAP_GPMC_STATUS)
STATUS_BUFF_EMPTY;
} while (!status);
}
@@ -1011,15 +1014,16 @@ static int omap_wait(struct mtd_info *mtd, struct
nand_chip *chip)
else
timeo += msecs_to_jiffies(20);
- writeb(NAND_CMD_STATUS 0xFF, info-reg.gpmc_nand_command);
+ omap_gpmc_write_reg(info-gpmc_cs, OMAP_GPMC_NAND_COMMAND,
+ NAND_CMD_STATUS);
while (time_before(jiffies, timeo)) {
- status = readb(info-reg.gpmc_nand_data);
+ status = omap_gpmc_read_reg(info-gpmc_cs, OMAP_GPMC_NAND_DATA);
if (status NAND_STATUS_READY)
break;
cond_resched();
}
- status = readb(info-reg.gpmc_nand_data);
+ status = omap_gpmc_read_reg(info-gpmc_cs, OMAP_GPMC_NAND_DATA);
return status;
}
@@ -1030,10 +1034,8 @@ static int omap_wait(struct mtd_info *mtd, struct
nand_chip *chip)
static int omap_dev_ready(struct mtd_info *mtd)
{
unsigned int val = 0;
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
- val = readl(info-reg.gpmc_status);
+ val = omap_gpmc_read_reg(0, OMAP_GPMC_STATUS);
if ((val 0x100) == 0x100) {
return 1;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 10/10] OMAP: GPMC: NAND: Don't pass NAND/ECC/BCH register adresses to NAND driver
The NAND driver now relies completely on the GPMC APIs to access
the NAND control lines and ECC/BCH engine. We no longer need
gpmc_update_nand_reg() and struct gpmc_nand_regs, so get rid of them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 2 --
arch/arm/mach-omap2/gpmc.c | 38
arch/arm/mach-omap2/gpmc.h | 1 -
drivers/mtd/nand/omap2.c | 2 --
include/linux/platform_data/mtd-nand-omap2.h | 5 +++-
5 files changed, 4 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 17cd393..565bd15 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -138,8 +138,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
if (err 0)
goto out_free_cs;
- gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
-
if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt)) {
dev_err(dev, Unsupported NAND ECC scheme selected\n);
return -EINVAL;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 944..fbd651e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -724,44 +724,6 @@ int gpmc_configure(int cmd, int wval)
}
EXPORT_SYMBOL(gpmc_configure);
-void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
-{
- int i;
-
- reg-gpmc_status = gpmc_base + GPMC_STATUS;
- reg-gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
- GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
- reg-gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
- GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * cs;
- reg-gpmc_nand_data = gpmc_base + GPMC_CS0_OFFSET +
- GPMC_CS_NAND_DATA + GPMC_CS_SIZE * cs;
- reg-gpmc_prefetch_config1 = gpmc_base + GPMC_PREFETCH_CONFIG1;
- reg-gpmc_prefetch_config2 = gpmc_base + GPMC_PREFETCH_CONFIG2;
- reg-gpmc_prefetch_control = gpmc_base + GPMC_PREFETCH_CONTROL;
- reg-gpmc_prefetch_status = gpmc_base + GPMC_PREFETCH_STATUS;
- reg-gpmc_ecc_config = gpmc_base + GPMC_ECC_CONFIG;
- reg-gpmc_ecc_control = gpmc_base + GPMC_ECC_CONTROL;
- reg-gpmc_ecc_size_config = gpmc_base + GPMC_ECC_SIZE_CONFIG;
- reg-gpmc_ecc1_result = gpmc_base + GPMC_ECC1_RESULT;
-
- for (i = 0; i GPMC_BCH_NUM_REMAINDER; i++) {
- reg-gpmc_bch_result0[i] = gpmc_base + GPMC_ECC_BCH_RESULT_0 +
- GPMC_BCH_SIZE * i;
- reg-gpmc_bch_result1[i] = gpmc_base + GPMC_ECC_BCH_RESULT_1 +
- GPMC_BCH_SIZE * i;
- reg-gpmc_bch_result2[i] = gpmc_base + GPMC_ECC_BCH_RESULT_2 +
- GPMC_BCH_SIZE * i;
- reg-gpmc_bch_result3[i] = gpmc_base + GPMC_ECC_BCH_RESULT_3 +
- GPMC_BCH_SIZE * i;
- reg-gpmc_bch_result4[i] = gpmc_base + GPMC_ECC_BCH_RESULT_4 +
- i * GPMC_BCH_SIZE;
- reg-gpmc_bch_result5[i] = gpmc_base + GPMC_ECC_BCH_RESULT_5 +
- i * GPMC_BCH_SIZE;
- reg-gpmc_bch_result6[i] = gpmc_base + GPMC_ECC_BCH_RESULT_6 +
- i * GPMC_BCH_SIZE;
- }
-}
-
int gpmc_get_client_irq(unsigned irq_config)
{
int i;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index 707f6d5..a91fab7 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -211,7 +211,6 @@ extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
struct gpmc_settings *gpmc_s,
struct gpmc_device_timings *dev_t);
-extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 6b0f953..e894e65 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -163,7 +163,6 @@ struct omap_nand_info {
} iomode;
u_char *buf;
int buf_len;
- struct gpmc_nand_regs reg;
/* fields specific for BCHx_HW ECC scheme */
struct device *elm_dev;
struct device_node *of_node;
@@ -1547,7 +1546,6 @@ static int omap_nand_probe(struct platform_device *pdev)
info-pdev = pdev;
info-gpmc_cs = pdata-cs;
- info-reg = pdata-reg;
info-of_node = pdata-of_node;
info-ecc_opt = pdata-ecc_opt;
mtd
[RFC PATCH 02/10] mtd: nand: omap: Always use chip-ecc.steps for BCH sector count
Instead of hardcoding use the pre-calculated chip-ecc.steps for
configuring number of sectors to process with the BCH algorithm.
This also avoids unnecessary access to the ECC_CONFIG register in
omap_calculate_ecc_bch().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b8739c..6f3d7cd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1066,10 +1066,10 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
unsigned int ecc_size1, ecc_size0;
/* GPMC configurations for calculating ECC */
+ nsectors = chip-ecc.steps;
switch (ecc_opt) {
case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
bch_type = 0;
- nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1082,7 +1082,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
break;
case OMAP_ECC_BCH4_CODE_HW:
bch_type = 0;
- nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH4R_ECC_SIZE0;
@@ -1095,7 +1094,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
break;
case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
bch_type = 1;
- nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1108,7 +1106,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
break;
case OMAP_ECC_BCH8_CODE_HW:
bch_type = 1;
- nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH8R_ECC_SIZE0;
@@ -1121,7 +1118,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
break;
case OMAP_ECC_BCH16_CODE_HW:
bch_type = 0x2;
- nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = 0x01;
ecc_size0 = 52; /* ECC bits in nibbles per sector */
@@ -1176,6 +1172,7 @@ static int __maybe_unused omap_calculate_ecc_bch(struct
mtd_info *mtd,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ struct nand_chip *chip = mtd-priv;
int eccbytes= info-nand.ecc.bytes;
struct gpmc_nand_regs *gpmc_regs = info-reg;
u8 *ecc_code;
@@ -1183,7 +1180,7 @@ static int __maybe_unused omap_calculate_ecc_bch(struct
mtd_info *mtd,
u32 val;
int i, j;
- nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
+ nsectors = chip-ecc.steps;
for (i = 0; i nsectors; i++) {
ecc_code = ecc_calc;
switch (info-ecc_opt) {
--
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
[RFC PATCH 03/10] OMAP: GPMC: Introduce APIs to access NAND control registers
Introduce omap_gpmc_read_reg() and omap_gpmc_write_reg() so that the
NAND driver can access the required registers (only those specified in
enum omap_gpmc_reg).
The NAND driver must use these APIs instead of directly accesing the
NAND control registers as they belong to the GPMC controller's register space.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 88 +-
include/linux/omap-gpmc-nand.h | 40 +++
2 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644 include/linux/omap-gpmc-nand.h
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c0c281..92bbada 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -31,7 +31,7 @@
#include linux/of_device.h
#include linux/mtd/nand.h
#include linux/pm_runtime.h
-
+#include linux/omap-gpmc-nand.h
#include linux/platform_data/mtd-nand-omap2.h
#include asm/mach-types.h
@@ -167,10 +167,32 @@ static resource_size_t phys_base, mem_size;
static unsigned gpmc_capability;
static void __iomem *gpmc_base;
+struct gpmc_nand_reg {
+ void __iomem *command;
+ void __iomem *address;
+ void __iomem *data;
+};
+
+static struct gpmc_nand_reg gpmc_nand_reg_map[GPMC_CS_NUM];
+
static struct clk *gpmc_l3_clk;
static irqreturn_t gpmc_handle_irq(int irq, void *dev);
+static void gpmc_fill_nand_reg_map(void)
+{
+ int i;
+
+ for (i = 0; i gpmc_cs_num; i++) {
+ gpmc_nand_reg_map[i].command = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * i;
+ gpmc_nand_reg_map[i].address = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_ADDRESS + GPMC_CS_SIZE * i;
+ gpmc_nand_reg_map[i].data = gpmc_base + GPMC_CS0_OFFSET +
+ GPMC_CS_NAND_DATA + GPMC_CS_SIZE * i;
+ }
+}
+
static void gpmc_write_reg(int idx, u32 val)
{
writel_relaxed(val, gpmc_base + idx);
@@ -1720,6 +1742,7 @@ static int gpmc_probe(struct platform_device *pdev)
return rc;
}
+ gpmc_fill_nand_reg_map();
return 0;
}
@@ -1885,3 +1908,66 @@ void omap3_gpmc_restore_context(void)
}
}
}
+
+/**
+ * omap_gpmc_read_reg - Read the specified GPMC register
+ * @cs:chip select number
+ * @reg: GPMC register id
+ *
+ * Reads the specified register from the appropriate chip select region
+ * and returns the read value.
+ */
+u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg)
+{
+ if (!gpmc_dev)
+ return 0;
+
+ if (cs = gpmc_cs_num)
+ return 0;
+
+ switch (reg) {
+ case OMAP_GPMC_STATUS:
+ return gpmc_read_reg(GPMC_STATUS);
+ case OMAP_GPMC_NAND_COMMAND:
+ case OMAP_GPMC_NAND_ADDRESS:
+ return 0; /* command address regs can't be read */
+ case OMAP_GPMC_NAND_DATA:
+ return readb_relaxed(gpmc_nand_reg_map[cs].data);
+ default:
+ return 0;
+ }
+}
+
+/**
+ * omap_gpmc_write_reg - Write into the specified GPMC register
+ * @cs:chip select number
+ * @reg: GPMC register id
+ * @val: value to write
+ *
+ * Writes the value into the specified register in the appropriate
+ * chip select region.
+ */
+void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val)
+{
+ if (!gpmc_dev)
+ return;
+
+ if (cs = gpmc_cs_num)
+ return;
+
+ switch (reg) {
+ case OMAP_GPMC_STATUS:
+ gpmc_write_reg(GPMC_STATUS, val);
+ case OMAP_GPMC_NAND_COMMAND:
+ writeb_relaxed(val, gpmc_nand_reg_map[cs].command);
+ break;
+ case OMAP_GPMC_NAND_ADDRESS:
+ writeb_relaxed(val, gpmc_nand_reg_map[cs].address);
+ break;
+ case OMAP_GPMC_NAND_DATA:
+ writeb_relaxed(val, gpmc_nand_reg_map[cs].data);
+ break;
+ default:
+ break;
+ }
+}
diff --git a/include/linux/omap-gpmc-nand.h b/include/linux/omap-gpmc-nand.h
new file mode 100644
index 000..dcb2abe
--- /dev/null
+++ b/include/linux/omap-gpmc-nand.h
@@ -0,0 +1,40 @@
+/*
+ * OMAP NAND to GPMC custom API interface
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc. - http://www.ti.com
+ * Roger Quadros rog...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef _OMAP_GPMC_NAND_H_
+#define _OMAP_GPMC_NAND_H_
+
+/**
+ * Registers that need to be accessed by the OMAP NAND driver
+ */
+
+enum omap_gpmc_reg {
+ OMAP_GPMC_STATUS,
+ OMAP_GPMC_NAND_COMMAND,
+ OMAP_GPMC_NAND_ADDRESS,
+ OMAP_GPMC_NAND_DATA,
+};
+
+#ifdef
[RFC PATCH 01/10] mtd: nand: omap: Use a single hardware controller instance
There is only one NAND controller (ECC generator) that needs to be
shared among multiple devices. So point nand_chip-hwcontrol to
a single omap_hw_controller instance.
This way the NAND base driver can take care of serializing access
to this single controller (via nand_chip-controller-lock)
when multiple NAND devices are present.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f0ed92e..5b8739c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -149,8 +149,9 @@ static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd,
0x41, 0xbc, 0x10};
/* oob info generated runtime depending on ecc algorithm and layout selected */
static struct nand_ecclayout omap_oobinfo;
+static struct nand_hw_control omap_hw_controller;
+
struct omap_nand_info {
- struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
struct mtd_info mtd;
struct nand_chipnand;
@@ -1649,9 +1650,6 @@ static int omap_nand_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, info);
- spin_lock_init(info-controller.lock);
- init_waitqueue_head(info-controller.wq);
-
info-pdev = pdev;
info-gpmc_cs = pdata-cs;
info-reg = pdata-reg;
@@ -1672,7 +1670,13 @@ static int omap_nand_probe(struct platform_device *pdev)
info-phys_base = res-start;
- nand_chip-controller = info-controller;
+ /*
+* There is only one NAND controller (ECC generator) that needs to be
+* shared among multiple devices. The NAND base driver takes care of
+* serializing access to this single controller when multiple NAND
+* devices are present.
+*/
+ nand_chip-hwcontrol = omap_hw_controller;
nand_chip-IO_ADDR_W = nand_chip-IO_ADDR_R;
nand_chip-cmd_ctrl = omap_hwcontrol;
--
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: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
On 07/09/2014 01:48 PM, Tony Lindgren wrote: So we can certainly enable this in a generic way, however, this can only be done under the following conditions: Sorry forgot to mention why I think this can now be done in a generic way, that's because we have now runtime PM in Linux. I have a problem to follow here. I need set SET_RUNTIME_PM_OPS in .pm member of the driver. This is around for a while now maybe it wasn't around by the omap-serial was written but this doesn't matter now. As for the dw driver (as one of the gnomes points out) it shouldn't matter because it is enabled / disabled based on 8250's pm callback. So while the device is active and the 8250 core grabs puts the reference, nothing should change. Still a double check from Mika wouldn't hurt. If I understand the omap case correct (and please correct me if I don't) the 8250-omap driver assumes that the device can go to sleep after the probe function completes. This does not happen because pm_runtime_set_autosuspend_delay() sets the delay to -1. If the user changes this via sysfs, then the device might go to sleep and the IP block switched of. Therefore we need the runtime pm callbacks in 8250-core before the register access because we can't access the it otherwise. The core should wake us up in case there is incoming RX action to be handled so we can restore register's content. And for TX we have the proper pm hooks. The dw driver also only disables / enables the clock. So they don't lose the register's content like omap does. Thus they don't need the one struct I exported. I don't think that it makes sense to make this restore/save part generic if this what it is about. OMAP at least has a few registers more to take care of and set-termios is already different. 1. We can save and restore the serial register context and detect when context was lost in the serial driver. The context loss can be detected by looking at some registers that are only initialized during init. A register check on restore context? DLL+DLH might be a good hint here since its value should be 0 in the running case. OK yeah that would be a generic way to do it potentially ;) Note that all the context_loss_cnt stuff in omap-serial.c can then be ignored, that's still only needed for the omap3 legacy mode booting case and won't be needed much longer. Ah. The way the code reads, it is just an optimization in case the core didn't go off after all so we don't have to restore the registers. 2. There's a way for the serial RX pin to wake the SoC. On some omaps there's a separate pin specific wake-up interrupt that can be used for that. That one would be handled by omap separately. OK great. 3. The serial PM features must be only enabled if requested by the user via sysfs. Typically extra latency and loss of the first RX character occur which is not acceptable to most applications. Unless I'm mistaken the omap driver now initializes the timeout to -1. So nothing happens unless this is enabled separately. Yes that's the only safe approach so the serial port behaves in the standard Linux way unless specifically requested by the user. Regards, Tony Sebastian -- 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: gpio-omap: wakeup mask
On 09.07.2014 12:41, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140709 03:18]:
Hey Tony, all
On 04.07.2014 09:27, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140702 05:12]:
Hi everyone,
we have a device with an am335x and are using some gpios on bank0 to
wake up the device from suspend to ram.
We have some user buttons which are configured in the devicetree as
gpio-keys and one power-key which should wake up the device:
buttons {
power {
label = Power;
gpios = gpio0 6 1;
linux,code = 116;
gpio-key,wakeup;
};
one {
label = One;
gpios = gpio0 11 1;
linux,code = 2;
};
: : :
}
The problem is, that the device wakes up on any trigger on bank 0. No
matter which button was pressed. gpio-key,wakeup seems not to have any
influence.
Now, if I comment the following lines out in drivers/gpio/gpio-omap.c :
set_gpio_trigger(...).
321
322 if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
323_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
324 bank-context.wake_en =
325readl_relaxed(bank-base + bank-regs-wkup_en);
326 }
327
Everything works as expected. But I don't really understand why? Is this
a bug, or does this break something else I have not discovered yet?
The GPIO wake-up events are working from off-idle for omap3
the last time I checked, so sounds like this is some am335x
related issue.
Ok, that sounds reasonable.
What does your bank-context.wake_en mask get set to with this code?
by calling 'echo mem /sys/power/state' followed by a wakeup, I get the
following:
[ 28.992866] bank-context-wake_en = 00080040
[ 29.020974] PM: noirq resume of devices complete after 22.439 msecs
I guess that's for gpio bank 0 with no bit 11 as your dts has it
configured.
Yes that's right. I forgot to print the context, too. If I do so, it's:
[ 31.034972] bank-base = F9E07000 gpio = 6 bank-context-wake_en =
00080040
respectively:
[ 31.846992] bank-base = F9E07000 gpio = 11 bank-context-wake_en =
00080040
If you just comment out the _gpio_rmw part above do
things work as expected?
Yes. It only wakes up on gpio 6 not on gpio 11 anymore.
Then if that works as expected, maybe write only some unused bits
into wkup_en register and see if it still wakes to all events while
it should not?
If I use the following testcode, everything works as expected:
//WARN(true, WARN: bank-base = %08X\n, bank-base);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
//_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
writel(0xABC0, base + bank-regs-wkup_en);
bank-context.wake_en = readl_relaxed(bank-base +
bank-regs-wkup_en);
printk(bank-base = %08X gpio = %i bank-context-wake_en = %08X\n,
bank-base, gpio, bank-context.wake_en);
}
This produces the following output:
[ 35.319228] PM: Syncing filesystems ... done.
[ 35.358702] Freezing user space processes ... (elapsed 0.003 seconds)
done.
[ 35.369754] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[ 35.380734] PM: Sending message for entering DeepSleep mode
[ 35.515932] bank-base = F9E07000 gpio = 19 bank-context-wake_en =
ABC0
[ 35.529319] PM: suspend of devices complete after 137.218 msecs
[ 35.544410] PM: late suspend of devices complete after 8.715 msecs
[ 35.562247] omap_hwmod: cpgmac0: _wait_target_disable failed
[ 35.569325] PM: noirq suspend of devices complete after 18.289 msecs
[ 35.576156] PM: GFX domain entered low power state
[ 35.576156] PM: Could not transition all powerdomains to target state
[ 35.576156] PM: Wakeup source GPIO0
[ 35.576156] PM Wakeup source extra: 0840
[ 35.576329] bank-base = F9E07000 gpio = 6 bank-context-wake_en =
ABC0
[ 35.583710] bank-base = F9E07000 gpio = 11 bank-context-wake_en =
ABC0
[ 35.614846] PM: noirq resume of devices complete after 22.582 msecs
[ 35.622009] bank-base = F9E07000 gpio = 6 bank-context-wake_en =
ABC0
[ 35.631798] bank-base = F9E07000 gpio = 11 bank-context-wake_en =
ABC0
[ 35.639511] bank-base = F9E07000 gpio = 19 bank-context-wake_en =
ABC0
[ 35.647116] bank-base = FA04C000 gpio = 9 bank-context-wake_en =
ABC0
[ 35.654547] bank-base = FA04C000 gpio = 12 bank-context-wake_en =
ABC0
[ 35.662015] bank-base = FA04C000 gpio = 13 bank-context-wake_en =
ABC0
[ 35.669526] bank-base = FA04C000 gpio = 14 bank-context-wake_en =
ABC0
[ 35.677039] bank-base = FA04C000 gpio = 15 bank-context-wake_en =
ABC0
[ 35.685035] bank-base = FA1AC000 gpio = 17 bank-context-wake_en =
ABC0
[ 35.692507] bank-base = FA1AC000 gpio = 18 bank-context-wake_en =
ABC0
[ 35.706466] PM: early resume of devices complete after 6.235 msecs
[ 35.715010] net eth0: initializing cpsw version 1.12 (0)
[ 35.794388] net eth0:
Re: [PATCH] ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
Hi Rostislav,
On 06/04/2014 05:24 PM, Rostislav Lisovy wrote:
GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated struct platform_device
gpmc_nand_device it is not possible to configure the system to
use more than one NAND device connected to the GPMC. This
modification makes it possible to use up to 8 NAND devices
connected to the GPMC controller.
Signed-off-by: Rostislav Lisovy lis...@merica.cz
---
Tested on custom AM335x board with two different NAND chips
(128 + 256 MiB) using GPMC configuration in FDT -- behaves
correctly.
arch/arm/mach-omap2/gpmc-nand.c | 79
+++--
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 4349e82..c5481a8 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -24,25 +24,6 @@
/* minimum size for IO mapping */
#define NAND_IO_SIZE4
-static struct resource gpmc_nand_resource[] = {
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .flags = IORESOURCE_IRQ,
- },
- {
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device gpmc_nand_device = {
- .name = omap2-nand,
- .id = 0,
- .num_resources = ARRAY_SIZE(gpmc_nand_resource),
- .resource = gpmc_nand_resource,
-};
-
static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* platforms which support all ECC schemes */
@@ -93,43 +74,41 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
{
int err = 0;
struct gpmc_settings s;
- struct device *dev = gpmc_nand_device.dev;
-
- memset(s, 0, sizeof(struct gpmc_settings));
+ struct platform_device *pdev;
+ struct resource gpmc_nand_res[] = {
+ { .flags = IORESOURCE_MEM, },
+ { .flags = IORESOURCE_IRQ, },
+ { .flags = IORESOURCE_IRQ, },
+ };
- gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+ BUG_ON(gpmc_nand_data-cs = GPMC_CS_NUM);
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
- (unsigned long *)gpmc_nand_resource[0].start);
+ (unsigned long *)gpmc_nand_res[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS %d, error %d\n,
- gpmc_nand_data-cs, err);
+ pr_err(omap2-gpmc: Cannot request GPMC CS %d, error %d\n,
+gpmc_nand_data-cs, err);
return err;
}
-
- gpmc_nand_resource[0].end = gpmc_nand_resource[0].start +
- NAND_IO_SIZE - 1;
-
- gpmc_nand_resource[1].start =
- gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
- gpmc_nand_resource[2].start =
- gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+ gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
+ gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
+ gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
if (gpmc_t) {
err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
if (err 0) {
- dev_err(dev, Unable to set gpmc timings: %d\n, err);
+ pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
return err;
}
}
+ memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
else
gpmc_set_legacy(gpmc_nand_data, s);
s.device_nand = true;
-
err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
if (err 0)
goto out_free_cs;
@@ -141,18 +120,34 @@ 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)) {
- dev_err(dev, Unsupported NAND ECC scheme selected\n);
- return -EINVAL;
+ pr_err(omap2-nand: Unsupported NAND ECC scheme selected\n);
+ err = -EINVAL;
+ goto out_free_cs;
}
- err = platform_device_register(gpmc_nand_device);
- if (err 0) {
- dev_err(dev, Unable to register NAND device\n);
- goto out_free_cs;
+
+ pdev = platform_device_alloc(omap2-nand, gpmc_nand_data-cs);
+ if (pdev) {
+ err = platform_device_add_resources(pdev, gpmc_nand_res,
+ ARRAY_SIZE(gpmc_nand_res));
+ if (!err)
+ pdev-dev.platform_data =
Re: [PATCH] Removes FIXME message in usb.c
Hello. On 07/09/2014 05:58 AM, Nicholas Krause wrote: This patch removes a fixme message in this file:wq for setting the usb 2 The vim's commands interspersed with text? :-) 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 [...] WBR, Sergei -- 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, Jul 07, 2014 at 05:50:09PM +, Paul Walmsley wrote:
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.
No, the driver doesn't do that. So I can clean that up, nice.
@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.)
Alright, thanks Paul.
About the deep idle states... I'm not sure, I couldn't find any explicit
wording about it in the am335x technical reference manual nor in in the
boneblack system reference manual.
According to the TRM the PRUSS lies in the PD_PER power domain, which is
powered down for the Deepsleep0 power mode. So I *guess* the PRUSS also
needs to be taken out of hard reset when waking up from such a state.
But there's no upstream support for these power modes on am33xx anyway,
and I'd assume that HWMOD_INIT_DEASSERT_HARD_RESET gets removed or
replaced once that lands. Which is probably what you meant by temporary.
FWIW, I'd be willing to look into that when the time comes and PRUSS gets
left behind.
Thanks,
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] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Wed, Jul 09, 2014 at 02:25:31AM -0700, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140708 01:32]:
* 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?
I guess no more comments. Took a look at the patch again, Sekhar, can
you please update the description with what has been discovered in this
thread and repost?
another thing to note is that as of today, there is no known way of
accessing power control register in *any* TI parts. That's quite
unfortunate :-(
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Wed, Jul 09, 2014 at 05:56:37PM +0530, Sekhar Nori wrote:
On Wednesday 09 July 2014 02:55 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140708 01:32]:
* 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?
I guess no more comments. Took a look at the patch again, Sekhar, can
you please update the description with what has been discovered in this
thread and repost?
How does the following sound:
---
AM437x has L2C-310 version r3p2 and ROM code on that device does not
at least my SoC has r3p3 (cache ID 0x9), other than that, commit log
looks good to my eyes.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Monday 07 July 2014 09:40 AM, 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.
Sorry for joining late on the thread. Yes the power control register API
isn't provided and write should be avoiding.
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
---
Right. Feel free add my ack if you need one.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
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) {
--
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 Wednesday 09 July 2014 08:39 AM, Russell King - ARM Linux wrote: On Wed, Jul 09, 2014 at 05:56:37PM +0530, Sekhar Nori wrote: On Wednesday 09 July 2014 02:55 PM, Tony Lindgren wrote: I guess no more comments. Took a look at the patch again, Sekhar, can you please update the description with what has been discovered in this thread and repost? How does the following sound: --- AM437x has L2C-310 version r3p2 and ROM code on that device 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. Power controller register setting doesn't make cache controller functional but it is for really clock gating and standby. So please reword, the above statement accordingly. 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. Instead of being vague here and below, I will just make it very simple as below. On OMAP SOCs using PL310 controllers, Power_ctrl register is not accessible from non-secure software on PL310 versions which supports it. The secure code takes care of setting it up correctly and the power transitions are proven on these devices. So lets add the ignore write check for PL310 Power_ctrl register write. From the public TRM available for OMAP4470, even on that device, ROM does not support writing to this register even though it uses a version of L2C-310 which has the register implemented. So this patch should take care of all variants of existing OMAPs. --- That sounds perfect, and explains why the change has to exist, and why it can't be fixed elsewhere. Thanks for providing the full reasoning in the commit message. -- 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
* Sebastian Andrzej Siewior bige...@linutronix.de [140709 05:45]: On 07/09/2014 01:48 PM, Tony Lindgren wrote: So we can certainly enable this in a generic way, however, this can only be done under the following conditions: Sorry forgot to mention why I think this can now be done in a generic way, that's because we have now runtime PM in Linux. I have a problem to follow here. I need set SET_RUNTIME_PM_OPS in .pm member of the driver. This is around for a while now maybe it wasn't around by the omap-serial was written but this doesn't matter now. Right, the lack of runtime PM was one of the reasons for doing omap-serial earlier. As for the dw driver (as one of the gnomes points out) it shouldn't matter because it is enabled / disabled based on 8250's pm callback. So while the device is active and the 8250 core grabs puts the reference, nothing should change. Still a double check from Mika wouldn't hurt. OK If I understand the omap case correct (and please correct me if I don't) the 8250-omap driver assumes that the device can go to sleep after the probe function completes. This does not happen because pm_runtime_set_autosuspend_delay() sets the delay to -1. Correct. And once the timeout is enabled, the serial driver autoidles itself using runtime PM based on the timeout value. And also please note that for runtime PM the wake-up events need to be always enabled, so the device_may_wakeup() checks should be only implemented for suspend and resume. I think I got that corrected for most part in omap-serial.c recently, but knowing that might reduce the confusion a bit :) If the user changes this via sysfs, then the device might go to sleep and the IP block switched of. Therefore we need the runtime pm callbacks in 8250-core before the register access because we can't access the it otherwise. Correct. And it's not just the 8250 idle state, it's the whole SoC getting powered down during idle and rebooted when waking to a timer interrupt or device interrupt. The core should wake us up in case there is incoming RX action to be handled so we can restore register's content. And for TX we have the proper pm hooks. The piece of code that runs in that case is the interrupt handler for the serial port. That handler could be separate from the regular serial port handler if necessary though and do a callback to the serial core code. But I don't know if that's needed. The dw driver also only disables / enables the clock. So they don't lose the register's content like omap does. Thus they don't need the one struct I exported. Right, enabling and disabling the clock is done too for omaps when the SoC hits retention idle. I don't think that it makes sense to make this restore/save part generic if this what it is about. OMAP at least has a few registers more to take care of and set-termios is already different. Yeah, and that can be done later on if others need it. 1. We can save and restore the serial register context and detect when context was lost in the serial driver. The context loss can be detected by looking at some registers that are only initialized during init. A register check on restore context? DLL+DLH might be a good hint here since its value should be 0 in the running case. OK yeah that would be a generic way to do it potentially ;) Note that all the context_loss_cnt stuff in omap-serial.c can then be ignored, that's still only needed for the omap3 legacy mode booting case and won't be needed much longer. Ah. The way the code reads, it is just an optimization in case the core didn't go off after all so we don't have to restore the registers. Well the interconnect code knows when the context was lost on omaps, but there's currently no Linux generic API for that. And since we can do it by checking some registers, it's best to implement it that way. 2. There's a way for the serial RX pin to wake the SoC. On some omaps there's a separate pin specific wake-up interrupt that can be used for that. That one would be handled by omap separately. OK great. 3. The serial PM features must be only enabled if requested by the user via sysfs. Typically extra latency and loss of the first RX character occur which is not acceptable to most applications. Unless I'm mistaken the omap driver now initializes the timeout to -1. So nothing happens unless this is enabled separately. Yes that's the only safe approach so the serial port behaves in the standard Linux way unless specifically requested by the user. Regards, Tony Sebastian -- 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
On 07/09/2014 03:29 AM, Tony Lindgren wrote:
* Suman Anna s-a...@ti.com [140708 10:57]:
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.
OK since we already have some .dts entries with ti,mbox-num-fifos and
ti,mbox-num-users I'd use those for now. Adding parsing for a generic
property can be done later on.
Alright, will stick to the existing properties.
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.
OK
Tony,
Depending on the agreement here, I may have to respin the OMAP
mailbox DT/hwmod cleanup series [1]
OK let me know.
I will refresh both this series and the mailbox DT/hwmod cleanup with
these changes, and post the patches tomorrow.
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: gpio-omap: wakeup mask
* Pascal Huerst pascal.hue...@gmail.com [140709 05:47]:
On 09.07.2014 12:41, Tony Lindgren wrote:
If you just comment out the _gpio_rmw part above do
things work as expected?
Yes. It only wakes up on gpio 6 not on gpio 11 anymore.
Then if that works as expected, maybe write only some unused bits
into wkup_en register and see if it still wakes to all events while
it should not?
If I use the following testcode, everything works as expected:
//WARN(true, WARN: bank-base = %08X\n, bank-base);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
//_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
writel(0xABC0, base + bank-regs-wkup_en);
bank-context.wake_en = readl_relaxed(bank-base +
bank-regs-wkup_en);
printk(bank-base = %08X gpio = %i bank-context-wake_en = %08X\n,
bank-base, gpio, bank-context.wake_en);
}
Hmm weird. It sounds like something like the following is happening:
1. The first GPIO bank is always powered, and does not need to set
wake-up events
2. When setting the GPIO wake-up events it seems that enabling any
wake-up event for the first (16?) bits wakes up the system
You might want to check this with some spare GPIOs not in the
first bank and see if you need the wake-up events and if enabling
some bits enables more than one GPIO for wake-up events.
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
[GIT PULL] omap fixes against v3.16-rc4
The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1: Linux 3.16-rc4 (2014-07-06 12:37:51 -0700) 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-rc4 for you to fetch changes up to 1d29a0722f6c38f79785c9ffb911730598de84e2: ARM: OMAP2+: Remove non working OMAP HDMI audio initialization (2014-07-08 01:08:44 -0700) Fixes for omaps for the -rc series. It's mostly fixes for clock rates, restart handling and phy regulators and SATA interconnect data. Also few build fixes related to the DSP driver in staging, and trivial stuff like removal of broken and soon to be unused platform data init for HDMI audio that would be good to get into the -rc series if not too late. Enric Balletbo i Serra (1): ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA. Guido Martínez (1): ARM: OMAP2+: Make GPMC skip disabled devices Jyri Sarha (1): ARM: OMAP2+: Remove non working OMAP HDMI audio initialization Nishanth Menon (1): ARM: DRA7/AM43XX: fix header definition for omap44xx_restart Peter Ujfalusi (2): ARM: dts: am335x-evm: Enable the McASP FIFO for audio ARM: dts: am335x-evmsk: Enable the McASP FIFO for audio Rajendra Nayak (1): ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates Roger Quadros (3): ARM: DRA7: hwmod: Fixup SATA hwmod ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on Suman Anna (2): ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver ARM: OMAP2+: create dsp device only on OMAP3 SoCs Tero Kristo (1): ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow Tony Lindgren (2): Merge branch 'for-v3.16-rc/clk-dt-fixes' of https://github.com/t-kristo/linux-pm into fixes-rc4 Merge tag 'for-v3.16-rc/omap-fixes-b' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.16/fixes arch/arm/boot/dts/am335x-evm.dts | 4 ++-- arch/arm/boot/dts/am335x-evmsk.dts| 4 ++-- arch/arm/boot/dts/am335x-igep0033.dtsi| 6 ++ arch/arm/boot/dts/dra7-evm.dts| 1 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++ arch/arm/mach-omap2/clkt_dpll.c | 2 +- arch/arm/mach-omap2/cm-regbits-34xx.h | 3 +++ arch/arm/mach-omap2/common.h | 3 ++- arch/arm/mach-omap2/devices.c | 28 arch/arm/mach-omap2/dsp.c | 10 ++ arch/arm/mach-omap2/gpmc.c| 2 +- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 18 +- arch/arm/mach-omap2/prm-regbits-34xx.h| 6 ++ 13 files changed, 53 insertions(+), 44 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: [GIT PULL] ARM: OMAP2: clock data migration to DT for 3.17 merge window
* Tero Kristo t-kri...@ti.com [140703 11:19]: Hi Tony, Posting this pull-request also early due to my holidays. Anyway, these patches were supposed to go in already during 3.16 merge window, but they missed it due to pending dependencies. Finalizes the move of OMAP24xx clock data to the DT, and also removes the legacy clock data. Might be good to try this branch out with n800 / 2420 hardware also as I don't have access to those. --- 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.17/omap2-use-dt-clks for you to fetch changes up to 6a194a6e2a8fa55e133936a124ed500aea434116: ARM: OMAP24xx: clock: remove legacy clock data (2014-07-02 15:59:03 +0300) OK thanks pulling this into omap-for-v3.17/dt. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 2/2] arm: dts: dra7: add crossbar device binding
* Tony Lindgren t...@atomide.com [140626 03:28]: * Sricharan R r.sricha...@ti.com [140626 01:36]: Hi Tony, On Thursday 26 June 2014 01:14 PM, Tony Lindgren wrote: * Sricharan R r.sricha...@ti.com [140626 00:29]: From: R Sricharan r.sricha...@ti.com There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The Peripheral irq requests are connected to only one crossbar input and the output of the crossbar is connected to only one controller's input line. The crossbar device is used to map a peripheral input to a free mpu's interrupt controller line. Here, adding a new crossbar device node and replacing all the peripheral interrupt numbers with its fixed crossbar input lines. I think these two patches need to be a single patch to avoid breaking booting for git bisect inbetween these patches? This does not cause booting issues. irq_desc gets allocated linearly, but that does not create boot issues. OK These are now applied on top of Jason's immutable irqchip branch and merged and pushed out into omap-for-v3.17/dt. Can you guys please test? 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: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
On 07/09/2014 05:12 PM, Tony Lindgren wrote: And also please note that for runtime PM the wake-up events need to be always enabled, so the device_may_wakeup() checks should be only implemented for suspend and resume. I think I got that corrected for most part in omap-serial.c recently, but knowing that might reduce the confusion a bit :) Ehm. I also added it to omap_8250_pm() as it is done in omap-serial (in serial_omap_pm()). Should I get rid of it in the latter? Sebastian -- 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 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] Removes FIXME message in usb.c
Ok, this has been fun to watch on lkml for a while now, but really, please, just stop doing this. Randomly searching the kernel source for FIXME lines and just commenting them out, isn't ok. Almost always, those lines are there because the original developer really doesn't know how else to resolve the issue. So, if the domain-specific-author doesn't have an idea of what to do, how does someone who is brand-new to the code know better? If you are looking for a task to do in the kernel, try drivers/staging/*/TODO for a list. Or look at the kernel janitor's list on kernelnewbies.org. Or try running the kernel and finding something that is broken for you and fixing that. Any of those would be better than randomly deleting FIXME lines. By doing that, you are just wasting maintainer's time. Which is the resource we have the least of at the moment. thanks, 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: [RFC PATCH 1/4] tty: serial: 8250 core: provide a function to export uart_8250_port
On 07/07/2014 03:09 PM, One Thousand Gnomes wrote: 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) done. Sebastian -- 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
Greg KH wrote on July 9th at 1:19 P.M. Ok, this has been fun to watch on lkml for a while now, but really, please, just stop doing this. Randomly searching the kernel source for FIXME lines and just commenting them out, isn't ok. Almost always, those lines are there because the original developer really doesn't know how else to resolve the issue. So, if the domain-specific-author doesn't have an idea of what to do, how does someone who is brand-new to the code know better? If you are looking for a task to do in the kernel, try drivers/staging/*/TODO for a list. Or look at the kernel janitor's list on kernelnewbies.org. Or try running the kernel and finding something that is broken for you and fixing that. Any of those would be better than randomly deleting FIXME lines. By doing that, you are just wasting maintainer's time. Which is the resource we have the least of at the moment. thanks, greg k-h Greg , I sent in another patch which enables omap_cfg_reg(USB2_SPEED) as stated in the fix me. The maintainers of this file stated to me this was dangerous due to the wires perhaps being shared with other parts of the board and we should depend on the boot loader to set this. The maintainers decided to remove this fix me not me based on their better understanding of this file. Cheers Nick On Wed, Jul 9, 2014 at 1:19 PM, Greg KH g...@kroah.com wrote: Ok, this has been fun to watch on lkml for a while now, but really, please, just stop doing this. Randomly searching the kernel source for FIXME lines and just commenting them out, isn't ok. Almost always, those lines are there because the original developer really doesn't know how else to resolve the issue. So, if the domain-specific-author doesn't have an idea of what to do, how does someone who is brand-new to the code know better? If you are looking for a task to do in the kernel, try drivers/staging/*/TODO for a list. Or look at the kernel janitor's list on kernelnewbies.org. Or try running the kernel and finding something that is broken for you and fixing that. Any of those would be better than randomly deleting FIXME lines. By doing that, you are just wasting maintainer's time. Which is the resource we have the least of at the moment. thanks, 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: [RFC PATCH 2/4] tty: serial: 8250 core: allow to overwrite export serial8250_startup()
On 07/07/2014 03:09 PM, One Thousand Gnomes wrote: 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 Thank you. I added to this patch the counterpart function (-shutdown) and therefore not yet adding the acked-by. Sebastian -- 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/6] tty: serial: 8250 core: provide a function to export uart_8250_port
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.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250/8250_core.c | 17 +
2 files changed, 19 insertions(+)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 1ebf853..34c3cd1 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -110,6 +110,8 @@ static inline void serial_dl_write(struct uart_8250_port
*up, int value)
up-dl_write(up, value);
}
+struct uart_8250_port *serial8250_get_port(int line);
+
#if defined(__alpha__) !defined(CONFIG_PCI)
/*
* Digital did something really horribly wrong with the OUT1 and OUT2
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 7a91c6d..6db2ee2 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2755,6 +2755,23 @@ static struct uart_ops serial8250_pops = {
static struct uart_8250_port serial8250_ports[UART_NR];
+/**
+ * serial8250_get_port - retrieve struct uart_8250_port
+ * @line: serial line number
+ *
+ * This function retrieves struct uart_8250_port for the specific line.
+ * This struct *must* *not* be used to perform a 8250 or serial core operation
+ * which is not accessible otherwise. Its only purpose is to make the struct
+ * accessible to the runtime-pm callbacks for context suspend/restore.
+ * The lock assumption made here is none because runtime-pm suspend/resume
+ * callbacks should not be invoked there is any operation performed on the
port.
+ */
+struct uart_8250_port *serial8250_get_port(int line)
+{
+ return serial8250_ports[line];
+}
+EXPORT_SYMBOL_GPL(serial8250_get_port);
+
static void (*serial8250_isa_config)(int port, struct uart_port *up,
unsigned short *capabilities);
--
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/6] tty: serial: 8250 core: add runtime pm
While comparing the OMAP-serial and the 8250 part of this I noticed that
the the latter does not use runtime-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access.
If I understand this correct, it should do nothing as long as
pm_runtime_use_autosuspend() + pm_runtime_enable() isn't invoked on the
device.
Cc: mika.westerb...@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 101 +++-
1 file changed, 88 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index d37eb08..1a91a89 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -38,6 +38,7 @@
#include linux/nmi.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/pm_runtime.h
#ifdef CONFIG_SPARC
#include linux/sunserialcore.h
#endif
@@ -553,10 +554,11 @@ static void serial8250_set_sleep(struct uart_8250_port
*p, int sleep)
* offset but the UART channel may only write to the corresponding
* bit.
*/
+ pm_runtime_get_sync(p-port.dev);
if ((p-port.type == PORT_XR17V35X) ||
(p-port.type == PORT_XR17D15X)) {
serial_out(p, UART_EXAR_SLEEP, sleep ? 0xff : 0);
- return;
+ goto out;
}
if (p-capabilities UART_CAP_SLEEP) {
@@ -571,7 +573,17 @@ static void serial8250_set_sleep(struct uart_8250_port *p,
int sleep)
serial_out(p, UART_EFR, 0);
serial_out(p, UART_LCR, 0);
}
+
+ if (!device_may_wakeup(p-port.dev)) {
+ if (sleep)
+ pm_runtime_forbid(p-port.dev);
+ else
+ pm_runtime_allow(p-port.dev);
+ }
}
+out:
+ pm_runtime_mark_last_busy(p-port.dev);
+ pm_runtime_put_autosuspend(p-port.dev);
}
#ifdef CONFIG_SERIAL_8250_RSA
@@ -1280,6 +1292,7 @@ static void serial8250_stop_tx(struct uart_port *port)
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
+ pm_runtime_get_sync(port-dev);
__stop_tx(up);
/*
@@ -1289,6 +1302,8 @@ static void serial8250_stop_tx(struct uart_port *port)
up-acr |= UART_ACR_TXDIS;
serial_icr_write(up, UART_ACR, up-acr);
}
+ pm_runtime_mark_last_busy(port-dev);
+ pm_runtime_put_autosuspend(port-dev);
}
static void serial8250_start_tx(struct uart_port *port)
@@ -1296,8 +1311,9 @@ static void serial8250_start_tx(struct uart_port *port)
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
+ pm_runtime_get_sync(port-dev);
if (up-dma !serial8250_tx_dma(up)) {
- return;
+ goto out;
} else if (!(up-ier UART_IER_THRI)) {
up-ier |= UART_IER_THRI;
serial_port_out(port, UART_IER, up-ier);
@@ -1318,6 +1334,9 @@ static void serial8250_start_tx(struct uart_port *port)
up-acr = ~UART_ACR_TXDIS;
serial_icr_write(up, UART_ACR, up-acr);
}
+out:
+ pm_runtime_mark_last_busy(port-dev);
+ pm_runtime_put_autosuspend(port-dev);
}
static void serial8250_stop_rx(struct uart_port *port)
@@ -1325,9 +1344,14 @@ static void serial8250_stop_rx(struct uart_port *port)
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
+ pm_runtime_get_sync(port-dev);
+
up-ier = ~UART_IER_RLSI;
up-port.read_status_mask = ~UART_LSR_DR;
serial_port_out(port, UART_IER, up-ier);
+
+ pm_runtime_mark_last_busy(port-dev);
+ pm_runtime_put_autosuspend(port-dev);
}
static void serial8250_enable_ms(struct uart_port *port)
@@ -1340,7 +1364,10 @@ static void serial8250_enable_ms(struct uart_port *port)
return;
up-ier |= UART_IER_MSI;
+ pm_runtime_get_sync(port-dev);
serial_port_out(port, UART_IER, up-ier);
+ pm_runtime_mark_last_busy(port-dev);
+ pm_runtime_put_autosuspend(port-dev);
}
/*
@@ -1530,9 +1557,17 @@ EXPORT_SYMBOL_GPL(serial8250_handle_irq);
static int serial8250_default_handle_irq(struct uart_port *port)
{
- unsigned int iir = serial_port_in(port, UART_IIR);
+ unsigned int iir;
+ int ret;
- return serial8250_handle_irq(port, iir);
+ pm_runtime_get_sync(port-dev);
+
+ iir = serial_port_in(port, UART_IIR);
+ ret = serial8250_handle_irq(port, iir);
+
+ pm_runtime_mark_last_busy(port-dev);
+ pm_runtime_put_autosuspend(port-dev);
+ return ret;
}
/*
@@ -1790,11 +1825,16 @@ static unsigned int serial8250_tx_empty(struct
uart_port *port)
unsigned long
[PATCH 6/6] tty: serial: Add 8250-core based omap driver
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The longterm goal is to provide the same functionality as the
current OMAP uart driver and hopefully DMA support which could borrowed
from the 8250-core.
It has been only tested as console UART on am335x-evm and dra7-evm.
The device name is ttyS based instead of ttyO. If a ttyO based node name
is required please ask udev for it.
Missing:
- throttle callback
v2…v3:
- wire up startup shutdown for wakeup-irq handling.
- RS485 handling (well the core does).
v1…v2:
- added runtime PM. Could somebody could plese double check
this? I seems to be enabled and nothing explodes. However
serial_omap_get_context_loss_count() enable_wakeup() are
NULL pointer (in the omap-serial driver). So I am not sure how
this supposed to work :)
- added omap_8250_set_termios()
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 8 +
drivers/tty/serial/8250/8250_omap.c | 881
drivers/tty/serial/8250/Kconfig | 9 +
drivers/tty/serial/8250/Makefile| 1 +
include/uapi/linux/serial_core.h| 3 +-
5 files changed, 901 insertions(+), 1 deletion(-)
create mode 100644 drivers/tty/serial/8250/8250_omap.c
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index bf06a4c..1cbfc8c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -263,6 +263,12 @@ static const struct serial8250_config uart_config[] = {
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_AFE,
},
+ [PORT_OMAP_16750] = {
+ .name = OMAP,
+ .fifo_size = 64,
+ .tx_loadsz = 64,
+ .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
+ },
[PORT_TEGRA] = {
.name = Tegra,
.fifo_size = 32,
@@ -1340,6 +1346,8 @@ static void serial8250_stop_rx(struct uart_port *port)
pm_runtime_get_sync(port-dev);
up-ier = ~UART_IER_RLSI;
+ if (port-type == PORT_OMAP_16750)
+ up-ier = ~UART_IER_RDI;
up-port.read_status_mask = ~UART_LSR_DR;
serial_port_out(port, UART_IER, up-ier);
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
new file mode 100644
index 000..b7fdbf6
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -0,0 +1,881 @@
+/*
+ * 8250-core based driver for the OMAP internal UART
+ *
+ * Copyright (C) 2014 Sebastian Andrzej Siewior
+ *
+ */
+
+#include linux/device.h
+#include linux/io.h
+#include linux/module.h
+#include linux/serial_8250.h
+#include linux/serial_core.h
+#include linux/serial_reg.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/of_irq.h
+#include linux/delay.h
+#include linux/pm_runtime.h
+#include linux/console.h
+#include linux/pm_qos.h
+
+#include 8250.h
+
+#define UART_DLL_EM 9
+#define UART_DLM_EM 10
+
+#define DEFAULT_CLK_SPEED 4800 /* 48 Mhz*/
+
+#define UART_ERRATA_i202_MDR1_ACCESS (1 0)
+#define OMAP_UART_WER_HAS_TX_WAKEUP(1 1)
+
+/* SCR register bitmasks */
+#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7)
+#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6)
+#define OMAP_UART_SCR_TX_EMPTY (1 3)
+
+/* MVR register bitmasks */
+#define OMAP_UART_MVR_SCHEME_SHIFT 30
+#define OMAP_UART_LEGACY_MVR_MAJ_MASK 0xf0
+#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
+#define OMAP_UART_LEGACY_MVR_MIN_MASK 0x0f
+#define OMAP_UART_MVR_MAJ_MASK 0x700
+#define OMAP_UART_MVR_MAJ_SHIFT8
+#define OMAP_UART_MVR_MIN_MASK 0x3f
+
+/* Enable XON/XOFF flow control on output */
+#define OMAP_UART_SW_TX0x08
+/* Enable XON/XOFF flow control on input */
+#define OMAP_UART_SW_RX0x02
+#define OMAP_UART_SW_CLR 0xf0
+#define OMAP_UART_TCR_TRIG 0x0f
+
+#define OMAP_UART_WER_MOD_WKUP 0x7f
+#define OMAP_UART_TX_WAKEUP_EN (1 7)
+
+#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
+
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
+struct serial8250_omap_priv {
+ int line;
+ u32 habit;
+ u32 fcr;
+ u32 mdr1;
+ u32 efr;
+ u32 quot;
+ u32 scr;
+ u32 wer;
+
+ bool is_suspending;
+ int wakeirq;
+ int wakeups_enabled;
+ u32 latency;
+ u32 calc_latency;
+ struct pm_qos_request pm_qos_request;
+ struct work_struct qos_work;
+};
+
+static u32 uart_read(struct uart_8250_port *up, u32 reg)
+{
+ return readl(up-port.membase + (reg up-port.regshift));
+}
+
+static void uart_write(struct
[no subject]
This is version three of the patch set. Unless something serious comes up I would drop the RFC on the next post. So far I should have everything covered up comparing to the omap-serial driver except for the throttle callbacks. And now I would slowly start looking into DMA support… Sebastian -- 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 4/6] tty: serial: 8250-core: reorder serial8250_stop_rx() serial8250_start_tx()
With the upcomming rs485 support it is required that
serial8250_stop_rx() is called from serial8250_start_tx(). With this
reordering there is no need for a forward declaration of the former
function.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 1a91a89..c7c3bf7 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1306,6 +1306,21 @@ static void serial8250_stop_tx(struct uart_port *port)
pm_runtime_put_autosuspend(port-dev);
}
+static void serial8250_stop_rx(struct uart_port *port)
+{
+ struct uart_8250_port *up =
+ container_of(port, struct uart_8250_port, port);
+
+ pm_runtime_get_sync(port-dev);
+
+ up-ier = ~UART_IER_RLSI;
+ up-port.read_status_mask = ~UART_LSR_DR;
+ serial_port_out(port, UART_IER, up-ier);
+
+ pm_runtime_mark_last_busy(port-dev);
+ pm_runtime_put_autosuspend(port-dev);
+}
+
static void serial8250_start_tx(struct uart_port *port)
{
struct uart_8250_port *up =
@@ -1339,21 +1354,6 @@ static void serial8250_start_tx(struct uart_port *port)
pm_runtime_put_autosuspend(port-dev);
}
-static void serial8250_stop_rx(struct uart_port *port)
-{
- struct uart_8250_port *up =
- container_of(port, struct uart_8250_port, port);
-
- pm_runtime_get_sync(port-dev);
-
- up-ier = ~UART_IER_RLSI;
- up-port.read_status_mask = ~UART_LSR_DR;
- serial_port_out(port, UART_IER, up-ier);
-
- pm_runtime_mark_last_busy(port-dev);
- pm_runtime_put_autosuspend(port-dev);
-}
-
static void serial8250_enable_ms(struct uart_port *port)
{
struct uart_8250_port *up =
--
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 5/6] tty: serial: 8250-core: add rs485 support
So after I stuffed the rs485 support from the omap-serial into
8250-omap, I've been looking at it and the only omap specific part was
the OMAP_UART_SCR_TX_EMPTY part. The driver has always TX_EMPTY set
because the 8250 core expects an interrupt after the TX fifo + shift
register is empty. The rs485 parts seems to wait for half fifo and then
again for the empty fifo. With this change gone it fits fine as generic
code and here it is.
It is expected that the potential rs485 user invokes
serial_omap_probe_rs485() to configure atleast RTS gpio which is a must
have property. The code has been taken from omap-serial driver and
received limited tested due to -ENODEV (the compiler said it works).
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 171
include/linux/serial_8250.h | 6 ++
2 files changed, 177 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index c7c3bf7..bf06a4c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -39,6 +39,8 @@
#include linux/mutex.h
#include linux/slab.h
#include linux/pm_runtime.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#ifdef CONFIG_SPARC
#include linux/sunserialcore.h
#endif
@@ -1281,10 +1283,34 @@ static void autoconfig_irq(struct uart_8250_port *up)
static inline void __stop_tx(struct uart_8250_port *p)
{
+ if (p-rs485.flags SER_RS485_ENABLED) {
+ int ret;
+
+ ret = (p-rs485.flags SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
+ if (gpio_get_value(p-rts_gpio) != ret) {
+ if (p-rs485.delay_rts_after_send 0)
+ mdelay(p-rs485.delay_rts_after_send);
+ gpio_set_value(p-rts_gpio, ret);
+ }
+ }
+
if (p-ier UART_IER_THRI) {
p-ier = ~UART_IER_THRI;
serial_out(p, UART_IER, p-ier);
}
+
+ if ((p-rs485.flags SER_RS485_ENABLED)
+ !(p-rs485.flags SER_RS485_RX_DURING_TX)) {
+ /*
+* Empty the RX FIFO, we are not interested in anything
+* received during the half-duplex transmission.
+*/
+ serial_out(p, UART_FCR, p-fcr | UART_FCR_CLEAR_RCVR);
+ /* Re-enable RX interrupts */
+ p-ier |= UART_IER_RLSI | UART_IER_RDI;
+ p-port.read_status_mask |= UART_LSR_DR;
+ serial_out(p, UART_IER, p-ier);
+ }
}
static void serial8250_stop_tx(struct uart_port *port)
@@ -1330,6 +1356,20 @@ static void serial8250_start_tx(struct uart_port *port)
if (up-dma !serial8250_tx_dma(up)) {
goto out;
} else if (!(up-ier UART_IER_THRI)) {
+
+ if (up-rs485.flags SER_RS485_ENABLED) {
+ int ret;
+
+ ret = (up-rs485.flags SER_RS485_RTS_ON_SEND) ? 1 : 0;
+ if (gpio_get_value(up-rts_gpio) != ret) {
+ gpio_set_value(up-rts_gpio, ret);
+ if (up-rs485.delay_rts_before_send 0)
+ mdelay(up-rs485.delay_rts_before_send);
+ }
+ if (!(up-rs485.flags SER_RS485_RX_DURING_TX))
+ serial8250_stop_rx(port);
+ }
+
up-ier |= UART_IER_THRI;
serial_port_out(port, UART_IER, up-ier);
@@ -2556,6 +2596,7 @@ serial8250_do_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_port_out(port, UART_FCR, UART_FCR_ENABLE_FIFO);
serial_port_out(port, UART_FCR, fcr); /* set fcr */
}
+ up-fcr = fcr;
serial8250_set_mctrl(port, port-mctrl);
spin_unlock_irqrestore(port-lock, flags);
pm_runtime_mark_last_busy(port-dev);
@@ -2811,6 +2852,124 @@ serial8250_verify_port(struct uart_port *port, struct
serial_struct *ser)
return 0;
}
+int serial8250_probe_rs485(struct uart_8250_port *up,
+ struct device *dev)
+{
+ struct serial_rs485 *rs485conf = up-rs485;
+ struct device_node *np = dev-of_node;
+ u32 rs485_delay[2];
+ enum of_gpio_flags flags;
+ int ret;
+
+ rs485conf-flags = 0;
+ if (!np)
+ return 0;
+
+ /* check for tx enable gpio */
+ up-rts_gpio = of_get_named_gpio_flags(np, rts-gpio, 0, flags);
+ if (up-rts_gpio == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (!gpio_is_valid(up-rts_gpio))
+ return 0;
+
+ ret = devm_gpio_request(dev, up-rts_gpio, serial_rts);
+ if (ret 0)
+ return ret;
+ ret = gpio_direction_output(up-rts_gpio,
+ flags SER_RS485_RTS_AFTER_SEND);
+ if (ret 0)
+
[PATCH 2/6] tty: serial: 8250 core: allow to overwrite export serial8250_startup()
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 and disabled at -shutdown() time.
v1…v2: add shutdown callback
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 22 --
include/linux/serial_8250.h | 2 ++
include/linux/serial_core.h | 2 ++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 6db2ee2..d37eb08 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1939,7 +1939,7 @@ static void serial8250_put_poll_char(struct uart_port
*port,
#endif /* CONFIG_CONSOLE_POLL */
-static int serial8250_startup(struct uart_port *port)
+int serial8250_do_startup(struct uart_port *port)
{
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
@@ -2191,8 +2191,17 @@ static int serial8250_startup(struct uart_port *port)
return 0;
}
+EXPORT_SYMBOL_GPL(serial8250_do_startup);
-static void serial8250_shutdown(struct uart_port *port)
+static int serial8250_startup(struct uart_port *port)
+{
+ if (port-startup)
+ return port-startup(port);
+ else
+ return serial8250_do_startup(port);
+}
+
+void serial8250_do_shutdown(struct uart_port *port)
{
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
@@ -2243,6 +2252,15 @@ static void serial8250_shutdown(struct uart_port *port)
if (port-irq)
serial_unlink_irq_chain(up);
}
+EXPORT_SYMBOL_GPL(serial8250_do_shutdown);
+
+static void serial8250_shutdown(struct uart_port *port)
+{
+ if (port-shutdown)
+ port-shutdown(port);
+ else
+ serial8250_do_shutdown(port);
+}
static unsigned int serial8250_get_divisor(struct uart_port *port, unsigned
int baud)
{
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index af47a8a..0ec21ec 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -114,6 +114,8 @@ extern void serial8250_early_out(struct uart_port *port,
int offset, int value);
extern int setup_early_serial8250_console(char *cmdline);
extern void serial8250_do_set_termios(struct uart_port *port,
struct ktermios *termios, struct ktermios *old);
+extern int serial8250_do_startup(struct uart_port *port);
+extern void serial8250_do_shutdown(struct uart_port *port);
extern void serial8250_do_pm(struct uart_port *port, unsigned int state,
unsigned int oldstate);
extern int fsl8250_handle_irq(struct uart_port *port);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5bbb809..6f20ff0 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -122,6 +122,8 @@ struct uart_port {
void(*set_termios)(struct uart_port *,
struct ktermios *new,
struct ktermios *old);
+ int (*startup)(struct uart_port *port);
+ void(*shutdown)(struct uart_port *port);
int (*handle_irq)(struct uart_port *);
void(*pm)(struct uart_port *, unsigned int state,
unsigned int old);
--
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
[RFC v3] 8250-core based serial driver for OMAP
+Subject On 2014-07-09 19:49:31 [+0200], Sebastian Andrzej Siewior wrote: This is version three of the patch set. Unless something serious comes up I would drop the RFC on the next post. So far I should have everything covered up comparing to the omap-serial driver except for the throttle callbacks. And now I would slowly start looking into DMA support… Sebastian -- 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 5/6] tty: serial: 8250-core: add rs485 support
On Wed, Jul 09, 2014 at 07:49:36PM +0200, Sebastian Andrzej Siewior wrote:
So after I stuffed the rs485 support from the omap-serial into
8250-omap, I've been looking at it and the only omap specific part was
the OMAP_UART_SCR_TX_EMPTY part. The driver has always TX_EMPTY set
because the 8250 core expects an interrupt after the TX fifo + shift
register is empty. The rs485 parts seems to wait for half fifo and then
again for the empty fifo. With this change gone it fits fine as generic
code and here it is.
It is expected that the potential rs485 user invokes
serial_omap_probe_rs485() to configure atleast RTS gpio which is a must
have property. The code has been taken from omap-serial driver and
received limited tested due to -ENODEV (the compiler said it works).
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 171
include/linux/serial_8250.h | 6 ++
2 files changed, 177 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index c7c3bf7..bf06a4c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -39,6 +39,8 @@
#include linux/mutex.h
#include linux/slab.h
#include linux/pm_runtime.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#ifdef CONFIG_SPARC
#include linux/sunserialcore.h
#endif
@@ -1281,10 +1283,34 @@ static void autoconfig_irq(struct uart_8250_port *up)
static inline void __stop_tx(struct uart_8250_port *p)
{
+ if (p-rs485.flags SER_RS485_ENABLED) {
+ int ret;
+
+ ret = (p-rs485.flags SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
+ if (gpio_get_value(p-rts_gpio) != ret) {
+ if (p-rs485.delay_rts_after_send 0)
+ mdelay(p-rs485.delay_rts_after_send);
+ gpio_set_value(p-rts_gpio, ret);
Usually the delay for RS485 is done in bit times, not msec. Not sure
how you expect this to work. Not sure doing it in software is precise
enough either. It probably should be calculated based on the current
baudrate with a bit time rather than msec in the DT data. No one wants
to have to change the DT data to change the baud rate. After all this
is very often used with modbus and the modbus rules specify turn around
times in bit times.
I hope TI puts this into the UART in future designs where it belongs
(similar to what Exar and many others already did).
--
Len Sorensen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: omap-dmic: use managed interfaces
This patch moves data allocated using clk_put and
snd_soc_register_component to the corresponding managed interfaces and
does away with the functions to free memory in the probe and remove
functions. The probe function is no longer required and is completely
removed.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
sound/soc/omap/omap-dmic.c | 35 ---
1 file changed, 8 insertions(+), 27 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 6925d71..b315b27 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -466,7 +466,7 @@ static int asoc_dmic_probe(struct platform_device *pdev)
mutex_init(dmic-mutex);
- dmic-fclk = clk_get(dmic-dev, fck);
+ dmic-fclk = devm_clk_get(dmic-dev, fck);
if (IS_ERR(dmic-fclk)) {
dev_err(dmic-dev, cant get fck\n);
return -ENODEV;
@@ -475,8 +475,7 @@ static int asoc_dmic_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, dma);
if (!res) {
dev_err(dmic-dev, invalid dma memory resource\n);
- ret = -ENODEV;
- goto err_put_clk;
+ return -ENODEV;
}
dmic-dma_data.addr = res-start + OMAP_DMIC_DATA_REG;
@@ -484,34 +483,17 @@ static int asoc_dmic_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
dmic-io_base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(dmic-io_base)) {
- ret = PTR_ERR(dmic-io_base);
- goto err_put_clk;
- }
-
+ if (IS_ERR(dmic-io_base))
+ return PTR_ERR(dmic-io_base);
- 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;
+ return ret;
ret = omap_pcm_platform_register(pdev-dev);
if (ret)
- goto err_put_clk;
-
- return 0;
-
-err_put_clk:
- clk_put(dmic-fclk);
- return ret;
-}
-
-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 ret;
return 0;
}
@@ -529,7 +511,6 @@ static struct platform_driver asoc_dmic_driver = {
.of_match_table = omap_dmic_of_match,
},
.probe = asoc_dmic_probe,
- .remove = asoc_dmic_remove,
};
module_platform_driver(asoc_dmic_driver);
--
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: Anybody working on tidspbridge?
On 9.07.2014 10:07, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140708 11:40]: 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. I agree, not much has improved with this driver since it got added into staging except just compile fixes. Regards, Tony Well, recently I've sent a couple of patches which implement stuff from TODO [1]. However, with the migration to DT, my focus now is to have a kernel/userspace that boots at all and this leaves no free cycles for DSP. Maybe tidspbridge can be left in staging until DT migration is finished, that way me (and maybe other people) will have the time needed to try to implement what remains in TODO. Also, keep in mind there will (hopefully) be another omap3 end-user device released by the end of the year (Neo900), which most probably will gain more developers interested in fixing the DSP driver. Regards, Ivo [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=559c71fe5dc3bf2ecc55afb336145db7f0abf810 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=a3b0a48bd14c9ba4ca8d051b0c92d5bc3866 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=d30555853052bbec8497260ba888b7d696bed9b8 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 2/2] arm: dts: dra7: add crossbar device binding
Hi Tony, On Wednesday 09 July 2014 09:14 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140626 03:28]: * Sricharan R r.sricha...@ti.com [140626 01:36]: Hi Tony, On Thursday 26 June 2014 01:14 PM, Tony Lindgren wrote: * Sricharan R r.sricha...@ti.com [140626 00:29]: From: R Sricharan r.sricha...@ti.com There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The Peripheral irq requests are connected to only one crossbar input and the output of the crossbar is connected to only one controller's input line. The crossbar device is used to map a peripheral input to a free mpu's interrupt controller line. Here, adding a new crossbar device node and replacing all the peripheral interrupt numbers with its fixed crossbar input lines. I think these two patches need to be a single patch to avoid breaking booting for git bisect inbetween these patches? This does not cause booting issues. irq_desc gets allocated linearly, but that does not create boot issues. OK These are now applied on top of Jason's immutable irqchip branch and merged and pushed out into omap-for-v3.17/dt. Can you guys please test? I have tested omap-for-v3.17/dt on DRA7 EVM. Crossbar is working fine. Looks good to me. lokesh@a0131933lt:~/working/mainline/linux$ git describe v3.16-rc1-34-g6464099 Please find the logs here: http://paste.ubuntu.com/7773616/ Thanks and regards, Lokesh 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 -- 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
