[PATCH] gpio: pcf857x: restore the initial line state of all pcf lines
The reset values for all the PCF lines are high and hence on shutdown
we should drive all the lines high in order to bring it to the reset state.
This is actually required since pcf doesn't have a reset line and even after
warm reset (by invoking reboot in prompt) the pcf lines maintains it's
previous programmed state. This becomes a problem if the boards are designed
to work with the default initial state.
DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to MMC/SD and
this line should be driven high in order for the MMC/SD to be detected.
This line is modelled as regulator and the hsmmc driver takes care of enabling
and disabling it. In the case of 'reboot', during shutdown path as part of it's
cleanup process the hsmmc driver disables this regulator. This makes MMC boot
not functional.
Fixed it by driving high all the pcf lines.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/gpio/gpio-pcf857x.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 236708a..00b15b2 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -448,6 +448,14 @@ static int pcf857x_remove(struct i2c_client *client)
return status;
}
+static void pcf857x_shutdown(struct i2c_client *client)
+{
+ struct pcf857x *gpio = i2c_get_clientdata(client);
+
+ /* Drive all the I/O lines high */
+ gpio-write(gpio-client, BIT(gpio-chip.ngpio) - 1);
+}
+
static struct i2c_driver pcf857x_driver = {
.driver = {
.name = pcf857x,
@@ -456,6 +464,7 @@ static struct i2c_driver pcf857x_driver = {
},
.probe = pcf857x_probe,
.remove = pcf857x_remove,
+ .shutdown = pcf857x_shutdown,
.id_table = pcf857x_id,
};
--
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: __hci_cmd_sync() not suitable for nokia h4p
Hi! What needs to be done is the bring up of the device including the proper UART settings and speed and then just run the firmware downloads. All firmware files on the Nokia devices where just HCI commands with vendor specific details. Some from CSR, some from Broadcom and some from TI. You can actually decode them if you really want to. Shouldn't be that hard. Speed changes at the end of firmware load, but I guess that's detail? Anyway, patch would look like this. You should really look into providing hdev-setup() callback. That is normally the callback where you want to load the firmware. I can provide setup() callback and load firmware from there. I have created provisional device tree binding, and the driver still works. Some time ago you mentioned that with the big issues fixed, you'd be willing to take it into the tree. What way forward do you see? Would it make sense to re-enable the driver in staging, so that big changes could be applied, followed by renames? If the driver is clean, there is no point in taking it through staging. It can be cleaned up and then merged all together. Ok, so you can revert a4102f90e87cfaa3fdbed6fdf469b23f0eeb4bfd in your tree, and I can post patches against that? I think the important part is to focus on the N900 derivative with the Broadcom chip inside. And just ignore all the rest. So start small and do not try to carry the N770, N800, N810 hacks over. Well, I did remove non-relevant firmware loaders, and I can remove the switches for different firmware loaders, too, but spending time removing support for different hardware does not sound quite right. However you might want to check Neil Brown's patches for TTY-slave devices he just posted. Maybe the N900 devices should be exposed as TTY and we just attach N_HCI line discipline to it. If all the GPIO wiggling can be done automatically at TTY open, then that should be the way to go. I also send an email about using the new unconfigured stage to get this done cleanly. I seen them, but they don't help, I'm afraid. The GPIOs are used for power saving, and they are used in various places including the serial irq handler. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: __hci_cmd_sync() not suitable for nokia h4p
Hi!
I have created provisional device tree binding, and the driver still
works.
I don't have time to look at the code now, but I have some comments
regarding the binding.
uart2 {
+compatible = brcm,uart,bcm2048;
This does not look correct. The uart should not be overwritten. The
current h4p driver indeed implements a driver for the serial port,
but that's a) linux specific and does not belong in the DT and b)
should probably be changed in the mainline kernel.
Yes, bettter solution is needed here. But see the code, I don't see
how b) would be implemented.
interrupts-extended = intc 73 omap3_pmx_core OMAP3_UART2_RX;
pinctrl-names = default;
pinctrl-0 = uart2_pins;
+ device {
+ compatible = brcm,bcm2048;
+ uart = uart2;
You don't need a phandle to the parent device.
Ok.
+ reset-gpios = gpio3 27 GPIO_ACTIVE_HIGH; /* want 91 */
+ host-wakeup-gpios = gpio4 5 GPIO_ACTIVE_HIGH; /* want 101
*/
The host-wakeup should be mapped as irq, gpio2irq conversion
will happen ;)
Why? It is accessed as gpio, too.
+ chip-type = 3;
This should be set in the driver based on the compatible
value and not via DT data.
Ok
+ clocks = uart2_fck, uart2_ick;
+ clock-names = fck, ick;
These clocks you defined belong to the uart device and not to the
uart slave (bluetooth) device.
Ok. Why are they only needed in the bluetooth case?
+ bt-sysclk = 2;
I think this should be mapped cleanly in DT by adding a new clock
to the DTS file:
vctcxo_clock: clock {
compatible = fixed-clock;
#clock-cells = 0;
clock-frequency = 3840;
};
No. It seems that this selects baud rate during the chip init. I guess
I can just remove that one.
Then the bluetooth device can reference its clock device:
clocks = vctcxo_clock;
The same clock reference should be added to the wl1251 DT node :)
Feel free to do that, but I don't see how this one helps...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: __hci_cmd_sync() not suitable for nokia h4p
Hi Pavel, What needs to be done is the bring up of the device including the proper UART settings and speed and then just run the firmware downloads. All firmware files on the Nokia devices where just HCI commands with vendor specific details. Some from CSR, some from Broadcom and some from TI. You can actually decode them if you really want to. Shouldn't be that hard. Speed changes at the end of firmware load, but I guess that's detail? Anyway, patch would look like this. You should really look into providing hdev-setup() callback. That is normally the callback where you want to load the firmware. I can provide setup() callback and load firmware from there. I have created provisional device tree binding, and the driver still works. Some time ago you mentioned that with the big issues fixed, you'd be willing to take it into the tree. What way forward do you see? Would it make sense to re-enable the driver in staging, so that big changes could be applied, followed by renames? If the driver is clean, there is no point in taking it through staging. It can be cleaned up and then merged all together. Ok, so you can revert a4102f90e87cfaa3fdbed6fdf469b23f0eeb4bfd in your tree, and I can post patches against that? just treat this a submission of a new driver. I think the important part is to focus on the N900 derivative with the Broadcom chip inside. And just ignore all the rest. So start small and do not try to carry the N770, N800, N810 hacks over. Well, I did remove non-relevant firmware loaders, and I can remove the switches for different firmware loaders, too, but spending time removing support for different hardware does not sound quite right. Lets face it, you are not getting it upstream that way. If nobody has the hardware to test it or cares about the hardware anymore, then this should not be upstream in the first place. Make your life easier and get your hardware supported. Then someone can evolve this for older Nokia devices. But I am not taking code that nobody has tested. Keep it simple is really the only way to get this driver merged. There is so much old cruft in there that you are better off only caring about the N900 version of the hardware. However you might want to check Neil Brown's patches for TTY-slave devices he just posted. Maybe the N900 devices should be exposed as TTY and we just attach N_HCI line discipline to it. If all the GPIO wiggling can be done automatically at TTY open, then that should be the way to go. I also send an email about using the new unconfigured stage to get this done cleanly. I seen them, but they don't help, I'm afraid. The GPIOs are used for power saving, and they are used in various places including the serial irq handler. That is something that might need some extra work on it, but it seems that the general direction of TTY slaves is the right one. Anyway, the main order of business is really that it supports DT and that it can be compiled on every single platform and you could even load the driver on x86 without doing any harm. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode
The new usage of determine_rate and set_rate_and_parent calls for
OMAP DPLLs assumes the DPLLs must have two parents defined, even
if it is the same clock. Legacy clock data did not fullfill this
requirement and caused a boot crash. Fixed by adding the missing
parent information to the DPLL clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
Fixes: 2e1a7b014f (ARM: OMAP3+: DPLL: use determine_rate() and...)
Cc: Kevin Hilman khil...@kernel.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 5c5ebb4..644ff32 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -111,6 +111,7 @@ static struct clk dpll3_ck;
static const char *dpll3_ck_parent_names[] = {
sys_ck,
+ sys_ck,
};
static const struct clk_ops dpll3_ck_ops = {
@@ -733,6 +734,10 @@ static const char *corex2_fck_parent_names[] = {
DEFINE_STRUCT_CLK_HW_OMAP(corex2_fck, NULL);
DEFINE_STRUCT_CLK(corex2_fck, corex2_fck_parent_names, core_ck_ops);
+static const char *cpefuse_fck_parent_names[] = {
+ sys_ck,
+};
+
static struct clk cpefuse_fck;
static struct clk_hw_omap cpefuse_fck_hw = {
@@ -744,7 +749,7 @@ static struct clk_hw_omap cpefuse_fck_hw = {
.clkdm_name = core_l4_clkdm,
};
-DEFINE_STRUCT_CLK(cpefuse_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(cpefuse_fck, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk csi2_96m_fck;
@@ -775,7 +780,7 @@ static struct clk_hw_omap d2d_26m_fck_hw = {
.clkdm_name = d2d_clkdm,
};
-DEFINE_STRUCT_CLK(d2d_26m_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(d2d_26m_fck, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk des1_ick;
@@ -1046,7 +1051,7 @@ static struct clk_hw_omap dss2_alwon_fck_hw = {
.clkdm_name = dss_clkdm,
};
-DEFINE_STRUCT_CLK(dss2_alwon_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(dss2_alwon_fck, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk dss_96m_fck;
@@ -1368,7 +1373,7 @@ DEFINE_STRUCT_CLK(gpio1_dbck, gpio1_dbck_parent_names,
aes2_ick_ops);
static struct clk wkup_l4_ick;
DEFINE_STRUCT_CLK_HW_OMAP(wkup_l4_ick, wkup_clkdm);
-DEFINE_STRUCT_CLK(wkup_l4_ick, dpll3_ck_parent_names, core_l4_ick_ops);
+DEFINE_STRUCT_CLK(wkup_l4_ick, cpefuse_fck_parent_names, core_l4_ick_ops);
static struct clk gpio1_ick;
@@ -1862,7 +1867,7 @@ static struct clk_hw_omap hecc_ck_hw = {
.clkdm_name = core_l3_clkdm,
};
-DEFINE_STRUCT_CLK(hecc_ck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(hecc_ck, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk hsotgusb_fck_am35xx;
@@ -1875,7 +1880,7 @@ static struct clk_hw_omap hsotgusb_fck_am35xx_hw = {
.clkdm_name = core_l3_clkdm,
};
-DEFINE_STRUCT_CLK(hsotgusb_fck_am35xx, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(hsotgusb_fck_am35xx, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk hsotgusb_ick_3430es1;
@@ -2411,7 +2416,7 @@ static struct clk_hw_omap modem_fck_hw = {
.clkdm_name = d2d_clkdm,
};
-DEFINE_STRUCT_CLK(modem_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(modem_fck, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk mspro_fck;
@@ -2710,7 +2715,7 @@ static struct clk_hw_omap sr1_fck_hw = {
.clkdm_name = wkup_clkdm,
};
-DEFINE_STRUCT_CLK(sr1_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(sr1_fck, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk sr2_fck;
@@ -2724,7 +2729,7 @@ static struct clk_hw_omap sr2_fck_hw = {
.clkdm_name = wkup_clkdm,
};
-DEFINE_STRUCT_CLK(sr2_fck, dpll3_ck_parent_names, aes2_ick_ops);
+DEFINE_STRUCT_CLK(sr2_fck, cpefuse_fck_parent_names, aes2_ick_ops);
static struct clk sr_l4_ick;
--
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 1/2] ARM: OMAP2+: clock: fix DPLL code to use new determine rate APIs
While the change for determine_rate clock operation was merged,
the OMAP counterpart using these calls was overlooked for some reason,
and caused boot failures on at least OMAP4 platforms. Fixed by updating
the DPLL API calls to use the new parameters.
Signed-off-by: Tero Kristo t-kri...@ti.com
Fixes: 646cafc6aa (clk: Change clk_ops-determine_rate)
Cc: Tomeu Vizoso tomeu.viz...@collabora.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/dpll3xxx.c |6 +++---
arch/arm/mach-omap2/dpll44xx.c |6 +++---
include/linux/clk/ti.h |4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 20e120d..c2da2a0 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -474,7 +474,7 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
*/
long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_clk)
+ struct clk_hw **best_parent_clk)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
@@ -488,10 +488,10 @@ long omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
unsigned long rate,
if (__clk_get_rate(dd-clk_bypass) == rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
- *best_parent_clk = dd-clk_bypass;
+ *best_parent_clk = __clk_get_hw(dd-clk_bypass);
} else {
rate = omap2_dpll_round_rate(hw, rate, best_parent_rate);
- *best_parent_clk = dd-clk_ref;
+ *best_parent_clk = __clk_get_hw(dd-clk_ref);
}
*best_parent_rate = rate;
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 535822f..0e58e5a 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -223,7 +223,7 @@ out:
*/
long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_clk)
+ struct clk_hw **best_parent_clk)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
@@ -237,11 +237,11 @@ long omap4_dpll_regm4xen_determine_rate(struct clk_hw
*hw, unsigned long rate,
if (__clk_get_rate(dd-clk_bypass) == rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
- *best_parent_clk = dd-clk_bypass;
+ *best_parent_clk = __clk_get_hw(dd-clk_bypass);
} else {
rate = omap4_dpll_regm4xen_round_rate(hw, rate,
best_parent_rate);
- *best_parent_clk = dd-clk_ref;
+ *best_parent_clk = __clk_get_hw(dd-clk_ref);
}
*best_parent_rate = rate;
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 74e5341..55ef529 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -264,7 +264,7 @@ int omap3_noncore_dpll_set_rate_and_parent(struct clk_hw
*hw,
long omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_clk);
+ struct clk_hw **best_parent_clk);
unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
unsigned long parent_rate);
long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
@@ -273,7 +273,7 @@ long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_clk);
+ struct clk_hw **best_parent_clk);
u8 omap2_init_dpll_parent(struct clk_hw *hw);
unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate);
long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
--
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 0/2] ARM: OMAP2+: quick clock fixes for linux-next
Hi, These patches fix a couple of bugs in linux-next. I didn't see official patch for #1 anywhere so posted here, was discussed under a thread on linux-omap list though. -Tero -- To unsubscribe 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/5] ARM: OMAP3+: DPLL: use determine_rate() and set_rate_and_parent()
On 12/10/2014 09:41 PM, Kevin Hilman wrote: Hi Tero, On Fri, Oct 3, 2014 at 6:57 AM, Tero Kristo t-kri...@ti.com wrote: Currently, DPLLs are hiding the gory details of switching parent within set_rate, which confuses the common clock code and is wrong. Fixed by applying the new determine_rate() and set_rate_and_parent() functionality to any clock-ops previously using the broken approach. This patch also removes the broken legacy code. Signed-off-by: Tero Kristo t-kri...@ti.com This patch arrived in linux-next (as commit 2e1a7b014f9c) and broke the omap2plus_defconfig, non-DT boot for the omap3-beagle-xm. By default, there's no output on the console, but turning on DEBUG_LL, I got the crash below[1]. Reverting this commit on next-20141210 gets things booting again for me. Posted a fix to this problem today to l-o list. -Tero Kevin [1] [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] Unable to handle kernel paging request at virtual address 5f737973 [0.00] pgd = c0004000 [0.00] [5f737973] *pgd= [0.00] Internal error: Oops: 5 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-11367-g6791358f417e #85 [0.00] Hardware name: OMAP3 Beagle Board [0.00] task: c08da288 ti: c08ce000 task.ti: c08ce000 [0.00] PC is at strcmp+0x4/0x30 [0.00] LR is at clk_fetch_parent_index+0x80/0xd8 [0.00] pc : [c032f3dc]lr : [c04d81c0]psr: 61d3 [0.00] sp : c08cff20 ip : fp : [0.00] r10: c08ec168 r9 : 5f737973 r8 : 0001 [0.00] r7 : de00d280 r6 : c0770eb4 r5 : de00d284 r4 : [0.00] r3 : 0073 r2 : r1 : 5f737973 r0 : c0770eb5 [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 80004019 DAC: 0015 [0.00] Process swapper/0 (pid: 0, stack limit = 0xc08ce240) [0.00] Stack: (0xc08cff20 to 0xc08d) [0.00] ff20: c08ec168 c0770eb4 c08ebbf0 23c34600 07270e00 413fc082 dfeff140 c04d82b0 [0.00] ff40: c08ebbf0 07270e00 c08ec168 c08ec168 07270e00 001a 23c34600 c08ab890 [0.00] ff60: dfeff140 c04d8bfc 34300133 0190 c08ec168 c086ffc8 34300133 0190 [0.00] ff80: c0870318 0258 c09768c4 c09768c4 c09768c4 0001 [0.00] ffa0: c0976480 c08681a8 c086a114 c08aa1e8 c0862684 0002 c085eb08 [0.00] ffc0: c085e670 c08ab890 c0976694 [0.00] ffe0: c08d6968 c08ab88c c08dbc2c 80004059 80008074 [0.00] [c032f3dc] (strcmp) from [c04d81c0] (clk_fetch_parent_index+0x80/0xd8) [0.00] [c04d81c0] (clk_fetch_parent_index) from [c04d82b0] (clk_calc_new_rates+0x98/0x194) [0.00] [c04d82b0] (clk_calc_new_rates) from [c04d8bfc] (clk_set_rate+0x50/0x90) [0.00] [c04d8bfc] (clk_set_rate) from [c086ffc8] (omap3_clk_lock_dpll5+0x1c/0xb4) [0.00] [c086ffc8] (omap3_clk_lock_dpll5) from [c0870318] (omap3xxx_clk_init+0x2b8/0x398) [0.00] [c0870318] (omap3xxx_clk_init) from [c08681a8] (omap_clk_init+0x3c/0x50) [0.00] [c08681a8] (omap_clk_init) from [c086a114] (omap3_secure_sync32k_timer_init+0x8/0x58) [0.00] [c086a114] (omap3_secure_sync32k_timer_init) from [c0862684] (time_init+0x1c/0x30) [0.00] [c0862684] (time_init) from [c085eb08] (start_kernel+0x25c/0x3fc) [0.00] [c085eb08] (start_kernel) from [80008074] (0x80008074) [0.00] Code: e12fff1e e1a03000 eaf7 e4d03001 (e4d12001) [ -- To unsubscribe 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
3.19-rc0: video stops working after update
Hi! After updating tree based on -pali to 2756d373a3f45a3a9ebf4ac389f9e0e02bd35a93 (and trimming down dts to make it boot, as I'm still hiting dts size limit), video stops working. I also found this nastiness in dmesg: Ideas welcome. Best regards, Pavel [0.285583] Thumb binaries may crash randomly without this workaround [0.285644] RX-51: Registring OMAP3 HWRNG device [0.290679] hw-breakpoint: debug architecture 0x4 unsupported. [0.293182] In-band Error seen by MPU at address 0 [0.293243] [ cut here ] [0.293304] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0 xd4/0x124() [0.293365] Modules linked in: [0.293426] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-omap3-76150-g3d3c12d-dirty #737 [0.293487] Backtrace: [0.293548] [c0011630] (dump_backtrace) from [c00117cc] (show_stack+0x18/0x1c) [0.293579] r6:c06cad30 r5:00a6 r4: r3: [0.293670] [c00117b4] (show_stack) from [c056f86c] (dump_stack+0x20/0x28) [0.293731] [c056f84c] (dump_stack) from [c0036f90] (warn_slowpath_common+0x7c/0xb4) [0.293823] [c0036f14] (warn_slowpath_common) from [c0036fec] (warn_slowpath_null+0x24/0x2c) [0.293853] r8:0013 r7:f8001400 r6: r5: r4:04001b00 [0.293945] [c0036fc8] (warn_slowpath_null) from [c0225c84] (omap3_l3_app_irq+0xd4/0x124) [0.294036] [c0225bb0] (omap3_l3_app_irq) from [c00628dc] (handle_irq_event_percpu+0x54/0x164) [0.294097] r7: r6: r5:cf89ec40 r4:cf89ec40 [0.294158] [c0062888] (handle_irq_event_percpu) from [c0062a44] (handle_irq_event+0x58/0x8c) [0.294219] r10:cf803200 r9:2113 r8:000a r7:cf843ce0 r6: r5:cf89ec40 [0.294311] r4:cf8ed240 [0.294342] [c00629ec] (handle_irq_event) from [c0065478] (handle_level_irq+0xdc/0x15c) [0.294403] r5: r4:cf8ed240 [0.294464] [c006539c] (handle_level_irq) from [c0062130] (generic_handle_irq+0x28/0x38) [0.294494] r4:0013 r3:c006539c [0.294555] [c0062108] (generic_handle_irq) from [c0062300] (__handle_domain_irq+0x68/0xc4) [0.294616] r4:c07a9cf8 r3:0103 [0.294677] [c0062298] (__handle_domain_irq) from [c0008700] (omap_intc_handle_irq+0xbc/0xcc) [0.294738] r10:6113 r8: r7:c08d8700 r6:cf843ce0 r5:c07a9ed0 r4:000a [0.294830] [c0008644] (omap_intc_handle_irq) from [c0012280] (__irq_svc+0x40/0x74) [0.294891] Exception stack(0xcf843ce0 to 0xcf843d28) [0.294921] 3ce0: cf978600 c079fe88 0001 cf978600 c079fe88 001c [0.294982] 3d00: cf978634 2113 6113 cf843d54 cf843d28 cf843d28 c0063c50 c0063d2c [0.295043] 3d20: 6113 [0.295074] r8:cf978634 r7:cf843d14 r6: r5:6113 r4:c0063d2c r3:c0063c50 [0.295166] [c0063990] (__setup_irq) from [c00640f0] (setup_irq+0x48/0x90) [0.295227] r10:cf842000 r8: r7:8000 r6:c079fe88 r5:001c r4:cf978600 [0.295318] [c00640a8] (setup_irq) from [c0031a98] (omap_system_dma_probe+0x214/0x2fc) [0.295379] r6:001c r5:c07cb044 r4:0020 r3: [0.295471] [c0031884] (omap_system_dma_probe) from [c029aaac] (platform_drv_probe+0x50/0xac) [0.295532] r10:cf842000 r9: r8: r7:c079fe44 r6:fdfb r5:cf985e10 [0.295593] r4:ffed [0.295654] [c029aa5c] (platform_drv_probe) from [c029934c] (driver_probe_device+0x10c/0x22c) [0.295715] r7:c079fe44 r6: r5:cf985e10 r4:c08def30 [0.295776] [c0299240] (driver_probe_device) from [c0299500] (__driver_attach+0x94/0x98) [0.295837] r8:c07527f0 r7: r6:cf985e44 r5:c079fe44 r4:cf985e10 r3: [0.295928] [c029946c] (__driver_attach) from [c02979c8] (bus_for_each_dev+0x5c/0x90) [0.295989] r6:c029946c r5:c079fe44 r4: r3: [0.296081] [c029796c] (bus_for_each_dev) from [c0298e48] (driver_attach+0x24/0x28) [0.296112] r6:c07b0410 r5:cf881a80 r4:c079fe44 [0.296173] [c0298e24] (driver_attach) from [c0298ac8] (bus_add_driver+0xdc/0x1d8) [0.296264] [c02989ec] (bus_add_driver) from [c0299bf0] (driver_register+0x80/0xfc) [0.296295] r7:00b8 r6:cf988580 r5:c0789be0 r4:c079fe44 [0.296386] [c0299b70] (driver_register) from [c029a928] (__platform_driver_register+0x50/0x64) [0.296447] r5:c0789be0 r4:c0789be0 [0.296508] [c029a8d8] (__platform_driver_register) from [c0752808] (omap_system_dma_init+0x18/0x20) [0.296569] [c07527f0] (omap_system_dma_init) from [c0008998] (do_one_initcall+0x88/0x1cc) [0.296661] [c0008910] (do_one_initcall) from [c0744d94] (kernel_init_freeable+0xf0/0x1b8) [0.296691] r10:c0773014 r9:c0772ffc r8:c07445ec r7:00b8 r6:c07ca440 r5:0003 [0.296783] r4:c077e570 [0.296844] [c0744ca4] (kernel_init_freeable) from [c056b04c] (kernel_init+0x10/0xec) [0.296874] r10: r9: r8: r7: r6:
Re: [PATCH v4 0/6] Touchscreen performance related fixes
Hello, I have tried your patches by cloning [1] and copying the relevant files over the kernel I've cloned from [2]. It compiles runs, but I'm seeing lots of pen-down/pen-up events when I'm not touching the screen. Any suggestions? Hardware: Beaglebone Black with BB-View 4.3 Cape from Farnell [1] git clone -b tsc-devel git://git.ti.com/kernel/tsc-adc.git (tsc-devel branch) [2] https://github.com/beagleboard/linux/tree/3.14 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] Touchscreen performance related fixes
On Friday 12 December 2014 02:10 AM, Sebastian Andrzej Siewior wrote: On 12/11/2014 09:34 PM, Nicolae Rosia wrote: Hello, Hi, Any updates on this series? I don't see it applied in [1] or [2]. I manage to freeze am335x-evm with those patches and I think Vignesh is looking into this. I was not able to reproduce this issue with my kernel configurations. I am yet to try with Sebastian's .config file. Not been able work on this. Regards, Nicolae Rosia Sebastian Regards, Vignesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 0/6] Touchscreen performance related fixes
-Original Message-
From: Catalin Crenguta [mailto:catalin.creng...@gmail.com]
I have tried your patches by cloning [1] and copying the relevant files over
the kernel I've cloned from [2].
It compiles runs, but I'm seeing lots of pen-down/pen-up events when I'm
not touching the screen.
Any suggestions?
How are you configuring ti,charge-delay in your dts? I've seen this behavior
on some custom boards where we were using a smaller charge delay (0x400) to
begin with, and by upping it to 0xb000 we resolved the issue. These patches
however already specified ti,charge-delay = 0xb000 by default so this would
surprise me that it's still seeing that issue. Was the touchscreen working as
expected before these new patches, or does it have issues both ways?
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
[PATCH] ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT
CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf071969b20f (cpufreq: cpu0: rename driver and internals to 'cpufreq_dt') Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with v3.18-rc1, commit bbcf071969b20f and fdc509b15eb3eb came in via different trees causing the resultant v3.18-rc1 to be non-functional for cpufreq as default supported with omap2plus_defconfig. Fixes: fdc509b15eb3eb (ARM: omap2plus_defconfig: Add cpufreq to defconfig) Signed-off-by: Nishanth Menon n...@ti.com --- NOTE: as of v3.18 tag, The following still need to be fixed - I do not have all the platforms impacted to make a generic change, so CCying folks who might be interested arch/arm/configs/shmobile_defconfig:CONFIG_GENERIC_CPUFREQ_CPU0=y arch/arm/configs/multi_v7_defconfig:CONFIG_GENERIC_CPUFREQ_CPU0=y arch/arm/configs/omap2plus_defconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 3e09286..5fc0dbe 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -68,7 +68,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y -CONFIG_GENERIC_CPUFREQ_CPU0=y +CONFIG_CPUFREQ_DT=y # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set CONFIG_CPU_IDLE=y CONFIG_BINFMT_MISC=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: OMAP5/DRA7: Fix counter frequency drift for AM572x errata i856
-sricharan, as the email ID is defunct.
On 12/11/2014 02:43 PM, Lennart Sorensen wrote:
On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but can also be 19.2 or 27MHz which result in much larger drift.
Why not just change the clock parent to something that is more
accurate like the 32k clk?
Since this is used to drive the master counter at 32.768KHz * 375 /
2 = 6.144MHz, the emulated speed for 20MHz is of by 570ppm, or about 43
seconds per day, and more than the 500ppm NTP is able to tolerate.
Checking the CTRL_CORE_BOOTSTRAP register can determine if the CPU
is using the real 32.768KHz crystal or the emulated SYSCLK1/610, and
Without digging into docs, This is just the boot configuration, right?
are we not able to reconfigure?
by known that the real counter frequency can be determined and used.
The real speed is then SYSCLK1 / 610 * 375 / 2 or SYSCLK1 * 375 / 1220.
This is unfortunately not integer math so the actual arch_timer_freq
needs to be precalculated.
Also the SYSCLK1 frequencies that have never been used by an omap
evaluation board were all missing a 0.
Please sign-off on you patch. use git format-patch -M -s to generate
patches. and when posting a series, use --cover-letter. Will also be
good to provide tests that show that this is indeed an issue on OMAP5
and DRA7 (considering the $subject here).
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4f61148..2e81511 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -513,11 +513,11 @@ static void __init realtime_counter_init(void)
rate = clk_get_rate(sys_clk);
/* Numerator/denumerator values refer TRM Realtime Counter section */
switch (rate) {
-case 120:
+case 1200:
num = 64;
den = 125;
break;
-case 130:
+case 1300:
num = 768;
den = 1625;
break;
@@ -529,11 +529,11 @@ static void __init realtime_counter_init(void)
num = 192;
den = 625;
break;
-case 260:
+case 2600:
num = 384;
den = 1625;
break;
-case 270:
+case 2700:
num = 256;
den = 1125;
break;
These should probably fall in as a separate patch.
@@ -557,6 +557,73 @@ static void __init realtime_counter_init(void)
writel_relaxed(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
arch_timer_freq = (rate / den) * num;
+
+if (soc_is_dra7xx()) {
+#define CTRL_CORE_BOOTSTRAP 0x4A0026C4
+#define SPEEDSELECT_MASK 0x0300
we dont usually define it like this.
+void __iomem *corebase;
+corebase = ioremap(CTRL_CORE_BOOTSTRAP, SZ_4);
+if (!corebase)
+pr_err(%s: ioremap failed\n, __func__);
+else {
also run ./scripts/checkpatch.pl --strict on your patch prior to
posting. try to ensure there are 0 warnings or checks.
+reg = readl_relaxed(corebase) SPEEDSELECT_MASK;
+iounmap(corebase);
+/*
+ * Errata i856 says the 32.768KHz crystal does
+ * not start at power on, so the CPU falls back in
+ * an emulated 32KHz clock instead. This causes
+ * the master counter frequency to not be what it
+ * was expected to be. This affects at least
+ * the AM572x 1.0 and 1.1 revisions.
+ * Of course any board built without a populated
+ * 32.768KHz crystal would also need this fix
+ * even if the CPU is fixed later.
+ *
+ * If the two speedselect bits are not 0, then the
+ * 32.768KHz clock driving the course counter that
+ * corrects the fine counter every time it ticks is
+ * actually rate/610 rather than 32.768KHz and we
+ * should compensate to avoid the 570ppm (At 20MHz,
+ * much worse at other rates) too fast system time.
+ *
+ * Precalculate the arch_timer_freq, since
+ * rate/610 isn't integer math and accuracy is
+ * desirable here.
+ */
+if (reg) {
+switch (rate) {
+case 1920:
+num = 375;
+
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Grygorii,
I've found this mail deep inside my inbox :-)
On Wednesday 30 July 2014 16:25:31 Grygorii Strashko wrote:
On 07/30/2014 03:06 AM, Laurent Pinchart wrote:
On Monday 28 July 2014 23:52:34 Grant Likely wrote:
On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote:
On 07/28/2014 05:05 PM, Grant Likely wrote:
On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko wrote:
Use clkops-clocks property to specify clocks handled by
clock_ops domain PM domain. Only clocks defined in clkops-clocks
set of clocks will be handled by Runtime PM through clock_ops
Pm domain.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/of/of_clk.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
index 35f5e9f..5f9b90e 100644
--- a/drivers/of/of_clk.c
+++ b/drivers/of/of_clk.c
@@ -86,11 +86,8 @@ int of_clk_register_runtime_pm_clocks(struct
device_node *np,
struct clk *clk;
int error;
-for (i = 0; (clk = of_clk_get(np, i)) !IS_ERR(clk); i++) {
-if (!clk_may_runtime_pm(clk)) {
-clk_put(clk);
-continue;
-}
+for (i = 0; (clk = of_clk_get_from_set(np, clkops, i))
+ !IS_ERR(clk); i++) {
This really looks like an ABI break to me. What happens to all the
existing platforms who don't have this new clkops-clocks in their
device tree?
Agree. This patch as is will break such platforms.
As possible solution for above problem - the NULL can be used as clock's
prefix by default and platform code can configure new value of clock's
prefix during initialization.
In addition, to make this solution full the of_clk_get_by_name() will
need to be modified too.
But note pls, this is pure RFC patches which I did to find out the
answer on questions: - What is better: maintain Runtime PM clocks
configuration in DT or in code?
In code. I don't think it is workable to embed runtime PM behaviour
into the DT bindings. I think there will be too much variance in what
hardware requires. We can create helpers to make this simpler, but I
don't think it is a good idea to set it up automatically without any
control from the driver itself.
- Where and when to call of_clk_register_runtime_pm_clocks()?
Bus notifier/ platform core/ device drivers
I would say in device drivers.
I tend to agree with that.
It will help here to take a step back and remember what the problem we're
trying to solve is.
At the root is clock management. Our system comprise many clocks, and they
need to be handled. The Common Clock Framework nicely models the clocks,
and offers an API for drivers to retrieve device clocks and control them.
Drivers can thus implement clock management manually without much pain.
A clock can be managed in roughly three different ways :
- it can be enabled at probe time and disabled at remove time ;
- it can be enabled right before the device leaves its idle state and
disabled when the device goes back to idle ; or
- it can be enabled and disabled in a more fine-grained, device-specific
manner.
The selected clock management granularity depends on constraints specific
to the device and on how aggressive power saving needs to be. Enabling
the clocks at probe time and disabling them at remove time is enough for
most devices, but leads to a high power consumption. For that reason the
second clock management scheme is often desired.
Managing clocks manually in the driver is a valid option. However, when
adding runtime PM to the equation, and realizing that the clocks need to
be enabled in the runtime PM resume handler and disabled in the suspend
handler, the clock management code starts looking very similar in most
drivers. We're thus tempted to factorize it away from the drivers into a
shared location.
It's important to note at this point that the goal here is only to
simplify drivers. Moving clock management code out of the drivers doesn't
(unless I'm missing something) open the door to new possibilities, it just
serves as a simplification.
Now, as Grygorii mentioned, differences between how a given IP core is
integrated in various SoCs can make clock management SoC-dependent. In the
vast majority of cases (which is really what we need to target, given that
our target is simplifying drivers) SoC integration can be described as a
list of clocks that must be managed. That list can be common to all
devices in a given SoC, or can be device-dependent as well.
That's actually a problem - now we have static list of managed clocks
per-SoC and not per device.
Few locations can be used to express a per-device list of per-SoC clocks.
We can have clocks lists in a per-SoC and per-device location, per-device
clocks lists in an SoC-specific
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Kevin, On Monday 08 September 2014 13:13:25 Kevin Hilman wrote: Laurent Pinchart laurent.pinch...@ideasonboard.com writes: On Monday 28 July 2014 23:52:34 Grant Likely wrote: On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote: On 07/28/2014 05:05 PM, Grant Likely wrote: On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko wrote: [...] - Where and when to call of_clk_register_runtime_pm_clocks()? Bus notifier/ platform core/ device drivers I would say in device drivers. I tend to agree with that. It will help here to take a step back and remember what the problem we're trying to solve is. [jumping in late, after Grygorii ping'd me about looking at this] Laurent, thanks for summarizing the problem so well. It helped me catchup on the discussion. You're welcome. Sorry for the very late reply. At the root is clock management. Our system comprise many clocks, and they need to be handled. The Common Clock Framework nicely models the clocks, and offers an API for drivers to retrieve device clocks and control them. Drivers can thus implement clock management manually without much pain. A clock can be managed in roughly three different ways : - it can be enabled at probe time and disabled at remove time ; - it can be enabled right before the device leaves its idle state and disabled when the device goes back to idle ; or - it can be enabled and disabled in a more fine-grained, device-specific manner. The selected clock management granularity depends on constraints specific to the device and on how aggressive power saving needs to be. Enabling the clocks at probe time and disabling them at remove time is enough for most devices, but leads to a high power consumption. For that reason the second clock management scheme is often desired. Managing clocks manually in the driver is a valid option. However, when adding runtime PM to the equation, and realizing that the clocks need to be enabled in the runtime PM resume handler and disabled in the suspend handler, the clock management code starts looking very similar in most drivers. We're thus tempted to factorize it away from the drivers into a shared location. It's important to note at this point that the goal here is only to simplify drivers. Moving clock management code out of the drivers doesn't (unless I'm missing something) open the door to new possibilities, it just serves as a simplification. I disagree. Actually, it opens up the door to lots of new possibilities that are crucial for fine-grained PM with QoS. It is not just simplification. There are many good reasons that some SoCs have moved all the management of PM-related clocks *out* of device drivers. More on that below... Now, as Grygorii mentioned, differences between how a given IP core is integrated in various SoCs can make clock management SoC-dependent. In the vast majority of cases (which is really what we need to target, given that our target is simplifying drivers) SoC integration can be described as a list of clocks that must be managed. That list can be common to all devices in a given SoC, or can be device-dependent as well. If we care about fine-grained PM, this is a way-too oversimplified version of what SoC integragion means. There are lots of pieces which fall under SoC integration, for example: clock domains, power domains, voltage domains, SoC-specific wakeup capabilities, etc. etc. Then, for fun throw in QoS constraints, and things get really exciting. IOW, if you care about fine-grained PM and QoS, you simply can't reduce SoC integration down to a list of clocks to be managed. Of course. I was talking about SoC integration for clocks, not about SoC integration in general. QoS makes this interesting as well because a device driver's decision to gate its own clocks may have serious repercussions on the wakeup latency of *other* devices in the same power domain. For example, the clock gating of the last active device in a powerdomain may cause the enclosing power- domain to be power gated, having a major impact on the wakup latency of *all* devices in that power domain. So if we're going to manage the list of PM-related clocks in the device driver, we'll also keep track of all the other devices in the same power domain, whether or not they're active, whether or not they have QoS constraints, etc. etc. Hopefully you can see that we're quickly way outside the scope of the IP block that the device driver is intended to manage. All of this is SoC integration knowledge, and IMO doen't belong in the device drivers. It belongs at the SoC integration level, and in todays kernel frameworks that means pm_domain/genpd. Ok, there's more to it than I initially thought. Let's see how we can make this happen then :-) Few locations can be used to express a per-device list of per-SoC clocks. We can have clocks
Re: [PATCH 2/2] ARM: OMAP3: clock: fix boot breakage in legacy mode
Hi Tero, Tero Kristo t-kri...@ti.com writes: The new usage of determine_rate and set_rate_and_parent calls for OMAP DPLLs assumes the DPLLs must have two parents defined, even if it is the same clock. Legacy clock data did not fullfill this requirement and caused a boot crash. Fixed by adding the missing parent information to the DPLL clocks. Signed-off-by: Tero Kristo t-kri...@ti.com Fixes: 2e1a7b014f (ARM: OMAP3+: DPLL: use determine_rate() and...) Cc: Kevin Hilman khil...@kernel.org I tested this on linux-next (next-20141210, same version where I found the bug) and this doesn't fix the boot problem. BTW, in testing this, I noticed that the OMAP clock code is still spitting out compile warnings[1]. These should cleaned up too. Kevin [1] ../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: initialization from incompatible pointer type [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:263:2: warning: (near initialization for 'dpll1_ck_ops.determine_rate') [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: initialization from incompatible pointer type [enabled by default] ../arch/arm/mach-omap2/cclock3xxx_data.c:376:2: warning: (near initialization for 'dpll4_ck_ops.determine_rate') [enabled by default] -- To unsubscribe 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: ARM: OMAP5/DRA7: Fix counter frequency drift for AM572x errata i856
On Fri, Dec 12, 2014 at 11:37:41AM -0600, Nishanth Menon wrote:
-sricharan, as the email ID is defunct.
So I noticed.
On 12/11/2014 02:43 PM, Lennart Sorensen wrote:
On Thu, Dec 11, 2014 at 03:41:16PM -0500, Lennart Sorensen wrote:
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but can also be 19.2 or 27MHz which result in much larger drift.
Why not just change the clock parent to something that is more
accurate like the 32k clk?
According to the documentation, it can not be changed. The course counter
runs from the external 32 crystal (which isn't working as per the errata)
and the only other choice is the emulated one. I suspect it is limited
because it has to run in low power mode, so it tries to stay in a small
part of the CPU. The same errata also means the internal RTC isn't
running, although why anyone would want a RTC that wasn't battery backed
I can't imagine, and I suspect every design wiill have a seperate external
RTC instead.
Without digging into docs, This is just the boot configuration, right?
are we not able to reconfigure?
Not according to anything I have seen in the documentation, and the
errata doesn't offer any options, and no one from TI has come back with
any options for changing it. They have agreed that my patch will make
it run correctly however.
Please sign-off on you patch. use git format-patch -M -s to generate
patches. and when posting a series, use --cover-letter. Will also be
good to provide tests that show that this is indeed an issue on OMAP5
and DRA7 (considering the $subject here).
Oh yeah I missed that line.
As for a test, running ntp will pretty quickly simply declare that the
system clock is more than 500ppm out and give up. Just using 'date'
you will see that it is off by over 10 seconds within 8 hours.
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4f61148..2e81511 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -513,11 +513,11 @@ static void __init realtime_counter_init(void)
rate = clk_get_rate(sys_clk);
/* Numerator/denumerator values refer TRM Realtime Counter section */
switch (rate) {
- case 120:
+ case 1200:
num = 64;
den = 125;
break;
- case 130:
+ case 1300:
num = 768;
den = 1625;
break;
@@ -529,11 +529,11 @@ static void __init realtime_counter_init(void)
num = 192;
den = 625;
break;
- case 260:
+ case 2600:
num = 384;
den = 1625;
break;
- case 270:
+ case 2700:
num = 256;
den = 1125;
break;
These should probably fall in as a separate patch.
OK, I will do that.
@@ -557,6 +557,73 @@ static void __init realtime_counter_init(void)
writel_relaxed(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
arch_timer_freq = (rate / den) * num;
+
+ if (soc_is_dra7xx()) {
+ #define CTRL_CORE_BOOTSTRAP 0x4A0026C4
+ #define SPEEDSELECT_MASK 0x0300
we dont usually define it like this.
+ void __iomem *corebase;
+ corebase = ioremap(CTRL_CORE_BOOTSTRAP, SZ_4);
+ if (!corebase)
+ pr_err(%s: ioremap failed\n, __func__);
+ else {
also run ./scripts/checkpatch.pl --strict on your patch prior to
posting. try to ensure there are 0 warnings or checks.
+ reg = readl_relaxed(corebase) SPEEDSELECT_MASK;
+ iounmap(corebase);
+ /*
+ * Errata i856 says the 32.768KHz crystal does
+ * not start at power on, so the CPU falls back in
+ * an emulated 32KHz clock instead. This causes
+ * the master counter frequency to not be what it
+ * was expected to be. This affects at least
+ * the AM572x 1.0 and 1.1 revisions.
+ * Of course any board built without a populated
+ * 32.768KHz crystal would also need this fix
+ * even if the CPU is fixed later.
+ *
+ * If the two speedselect bits are not 0, then the
+ * 32.768KHz clock driving the course counter that
+ * corrects the fine counter every time it ticks is
+ * actually rate/610 rather than 32.768KHz and we
+ * should compensate to avoid the 570ppm (At 20MHz,
+ * much worse at other rates) too fast system time.
+ *
+
Re: ARM: OMAP5/DRA7: Fix counter frequency drift for AM572x errata i856
On 14:23-20141212, Lennart Sorensen wrote: I was trying to avoid making the code mroe complicated for the other CPUs using this code, but I suppose since it runs only at boot once, that probably isn't really a great concern. we try and avoid soc_is or cpu_is as much as possible and depend usually on compatible to mark the change.. I will try changing the flow and send an updated version. k, thanks. lets go through your next rev to see if we can improve on the same. btw, nice catch :) - thanks for proposing a fix. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: OMAP5/DRA7: Fix counter frequency drift for AM572x errata i856
On Fri, Dec 12, 2014 at 01:40:01PM -0600, Nishanth Menon wrote: we try and avoid soc_is or cpu_is as much as possible and depend usually on compatible to mark the change.. Well you can't use the dtb really, since it depends on the chip revision and how it started at power on. After all if you purposely don't connect a 32KHz crystal to save board space and cost, then you will also need this fix to make time work properly, which is in fact what we will now be doing. k, thanks. lets go through your next rev to see if we can improve on the same. btw, nice catch :) - thanks for proposing a fix. Well we have been trying to get the system time to run well and have ntp happy for a few months now and it took the die designers quite a while to track down the power on problem with the 32KHz crystal. Unfortunately the emulation using 2000/610 is close enough that you don't notice it unless you are looking at time keeping issues. Of course if you try any of the other SYSCLK1 options for the CPU then time goes totally wrong. With a 19.2MHz crystal it was running almost 5% too slow which was very noticeable. -- 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
Re: [RFC PATCH 2/3] soc: ti: Add wkup_m3_ipc driver
On 11/26/2014 03:51 PM, Arnd Bergmann wrote:
On Wednesday 26 November 2014 15:38:09 Dave Gerlach wrote:
+
+static const struct wkup_m3_wakeup_src wakeups[] = {
+ {.irq_nr = 35, .src = USB0_PHY},
+ {.irq_nr = 36, .src = USB1_PHY},
+ {.irq_nr = 40, .src = I2C0},
+ {.irq_nr = 41, .src = RTC Timer},
+ {.irq_nr = 42, .src = RTC Alarm},
+ {.irq_nr = 43, .src = Timer0},
+ {.irq_nr = 44, .src = Timer1},
+ {.irq_nr = 45, .src = UART},
+ {.irq_nr = 46, .src = GPIO0},
+ {.irq_nr = 48, .src = MPU_WAKE},
+ {.irq_nr = 49, .src = WDT0},
+ {.irq_nr = 50, .src = WDT1},
+ {.irq_nr = 51, .src = ADC_TSC},
+ {.irq_nr = 0, .src = Unknown},
+};
This seems awfully specific to some SoC version, and not aware of
IRQ domains. It also seems to be only used in a dev_dbg statement,
so I guess you could just kill this off entirely.
This is determined by the firmware in use on the remote processor and works for
both am335x and am437x. However it is not required information and I'd be fine
with taking it out.
+static struct rproc *wkup_m3_get_rproc(struct device *dev)
+{
+ struct device_node *node;
+ struct rproc *rp;
+
+ node = of_parse_phandle(dev-of_node, ti,rproc, 0);
+ if (!node)
+ return NULL;
+
+ dev = bus_find_device(platform_bus_type, NULL, node, match);
+ if (!dev)
+ return NULL;
+
+ rp = dev_get_drvdata(dev);
+ return rp;
This is wrong on a number of levels. I suspect what you really want
is an interface exported from drivers/remoteproc that looks up
a 'struct rproc' and performs the necessary reference counting.
That one can just use of_find_node_by_phandle() to get to
a device_node and use that to look up the rproc device in
a linked list it maintains.
Added Ohad as I should have cc'd him in the first place..
Yes I agree that it's not the best solution. There used to be an
rproc_get/rproc_put api but that was removed, I'll look into adding
rproc_get_by_phandle into drivers/remoteproc as that would be ideal for this
situation and a cleaner way of doing it. Thanks for the comments.
Regards,
Dave
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: omap5/dra7xx: Fix counter frequency drift for AM572x errata i856.
Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
crystal is not enabled at power up. Instead the CPU falls back to using
an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
but can also be 19.2 or 27MHz which result in much larger drift.
Since this is used to drive the master counter at 32.768KHz * 375 /
2 = 6.144MHz, the emulated speed for 20MHz is of by 570ppm, or about 43
seconds per day, and more than the 500ppm NTP is able to tolerate.
Checking the CTRL_CORE_BOOTSTRAP register can determine if the CPU
is using the real 32.768KHz crystal or the emulated SYSCLK1/610, and
by known that the real counter frequency can be determined and used.
The real speed is then SYSCLK1 / 610 * 375 / 2 or SYSCLK1 * 75 / 244.
Signed-off-by: Len Sorensen lsore...@csclub.uwaterloo.ca
---
arch/arm/mach-omap2/timer.c | 120 +++
1 file changed, 87 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fb0cb2b..f00e4b4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -497,6 +497,7 @@ static void __init realtime_counter_init(void)
static struct clk *sys_clk;
unsigned long rate;
unsigned int reg, num, den;
+ bool errata_i856_workaround = false;
base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
if (!base) {
@@ -510,39 +511,93 @@ static void __init realtime_counter_init(void)
return;
}
+ if (soc_is_dra7xx()) {
+ #define CTRL_CORE_BOOTSTRAP 0x4A0026C4
+ #define SPEEDSELECT_MASK 0x0300
+ void __iomem *corebase;
+ corebase = ioremap(CTRL_CORE_BOOTSTRAP, SZ_4);
+ if (!corebase)
+ pr_err(%s: ioremap failed\n, __func__);
+ else {
+ reg = readl_relaxed(corebase) SPEEDSELECT_MASK;
+ iounmap(corebase);
+ /*
+* Errata i856 says the 32.768KHz crystal does
+* not start at power on, so the CPU falls back in
+* an emulated 32KHz clock instead. This causes
+* the master counter frequency to not be 6.144MHz
+* This affects at least the AM572x 1.0 and
+* 1.1 revisions.
+*
+* Of course any board built without a populated
+* 32.768KHz crystal would also need this fix
+* even if the CPU is fixed later.
+*
+* If the two speedselect bits are not 0, then the
+* 32.768KHz clock driving the course counter that
+* corrects the fine counter every time it ticks is
+* actually rate/610 rather than 32.768KHz and we
+* should compensate to avoid the 570ppm (At 20MHz,
+* much worse at other rates) too fast system time.
+*/
+ if (reg) {
+ errata_i856_workaround = true;
+ }
+ }
+ }
+
rate = clk_get_rate(sys_clk);
- /* Numerator/denumerator values refer TRM Realtime Counter section */
- switch (rate) {
- case 1200:
- num = 64;
- den = 125;
- break;
- case 1300:
- num = 768;
- den = 1625;
- break;
- case 1920:
- num = 8;
- den = 25;
- break;
- case 2000:
- num = 192;
- den = 625;
- break;
- case 2600:
- num = 384;
- den = 1625;
- break;
- case 2700:
- num = 256;
- den = 1125;
- break;
- case 3840:
- default:
- /* Program it for 38.4 MHz */
- num = 4;
- den = 25;
- break;
+ if (errata_i856_workaround) {
+ /*
+* Realtime Counter frequency is not based on a real
+* 32.768KHz time source, so calculate the real resulting
+* frequency instead. It is not 6.144MHz in this case.
+*
+* The frequency is always rate / 610 + 375 / 2 which
+* is rate * 244 / 75 and will fit in 32 bit for all rates.
+*
+* The multiplication has to be first to keep accuracy
+* with integer math as high as possible.
+*/
+ num = 75;
+ den = 244;
+ arch_timer_freq = (rate *
[PATCH 1/2] ARM: omap5/dra7xx: Fix frequency typos.
The switch statement of the possible list of SYSCLK1 frequencies is
missing a 0 in 4 out of the 7 frequencies.
Signed-off-by: Len Sorensen lsore...@csclub.uwaterloo.ca
---
arch/arm/mach-omap2/timer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4f61148..fb0cb2b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -513,11 +513,11 @@ static void __init realtime_counter_init(void)
rate = clk_get_rate(sys_clk);
/* Numerator/denumerator values refer TRM Realtime Counter section */
switch (rate) {
- case 120:
+ case 1200:
num = 64;
den = 125;
break;
- case 130:
+ case 1300:
num = 768;
den = 1625;
break;
@@ -529,11 +529,11 @@ static void __init realtime_counter_init(void)
num = 192;
den = 625;
break;
- case 260:
+ case 2600:
num = 384;
den = 1625;
break;
- case 270:
+ case 2700:
num = 256;
den = 1125;
break;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: omap5/dra7xx counter frequency fixes
While trying to deal with errata i856 on the dra7xx I encountered some obvious typos in the frequencies checked in timer.c, so those are being fixed in case anyone ever tries to use one of them. Also implement a fix for errata i856. Without the fix the time on the system will get ahead by 43 seconds per day if SYSCLK1 is 20MHz, which it is on the EVM boards as well as the other boards I am currently aware of. ntp declares that the system time drifts by over 500ppm (the maximum ntp will tolerate). To fix it, check the status register to determine if the 32.768KHz clock source is real (driven by an external crystal) or emulated (SYSCLK1 / 610), and if it is emulated use the appropriate numerator and divisor to make the fine master counter match the coarse master counter (which is driven directly from the 32KHz clock (real or emulated) with a fixed multiplier of 375 / 2). Making the fine counter run at a frequency different from the coarse counter is not an option, as the value in the fine counter is updated to match the coarse counter if they ever get out of sync. With 19.2MHz installed on the board, the clock runs almost 5% slow. With the change in place, ntp runs with a drift of around 3ppm on all boards I have tried which is well within the spec of the crystals used for SYSCLK1. Even if the errata is fixed in future revisions of the chip, there is still the option of someone purposely not connecting a 32.768KHz crystal to save cost or board space, and relying on the emulated clock instead, in which case this correction will still be necessary. Len Sorensen (2): ARM: omap5/dra7xx: Fix frequency typos. ARM: omap5/dra7xx: Fix counter frequency drift for AM572x errata i856. arch/arm/mach-omap2/timer.c | 120 +++ 1 file changed, 87 insertions(+), 33 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
