Re: [PATCH] ARM: OMAP5: DSS hwmod data
On 16/03/14 13:41, Dmitry Lifshitz wrote: Hi Tomi, (resending in the text format) Where can I get those unpublished omap5 and omap5-uevm display patches to test the video out with this patch? I'll appreciate your assistance in additional setup (like required uEvm .dts changes and DSI panel connection short guide). git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-pyra I've since added omap5 hdmi support, so omap5-uevm's hdmi output works on that branch. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] ASoC: tlv320aic31xx: Turn power off only once.
Regulator code keep count of enables and disables. Double disable causes an ugly warning. Signed-off-by: Jyri Sarha jsa...@ti.com --- sound/soc/codecs/tlv320aic31xx.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c index 89f808b..07ddec3 100644 --- a/sound/soc/codecs/tlv320aic31xx.c +++ b/sound/soc/codecs/tlv320aic31xx.c @@ -1021,7 +1021,8 @@ static int aic31xx_set_bias_level(struct snd_soc_codec *codec, } break; case SND_SOC_BIAS_OFF: - aic31xx_power_off(codec); + if (codec-dapm.bias_level == SND_SOC_BIAS_STANDBY) + aic31xx_power_off(codec); break; } codec-dapm.bias_level = level; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] net: cpsw: Add control-module macid driver
Hello Markus, On Sat, Mar 15, 2014 at 02:07:42PM +0100, Markus Pargmann wrote: This driver extracts the hardware macid from the control module of am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw to get the macid from within the processor. Signed-off-by: Markus Pargmann m...@pengutronix.de --- .../devicetree/bindings/net/cpsw-ctrl-macid.txt| 32 + drivers/net/ethernet/ti/Kconfig| 1 + drivers/net/ethernet/ti/Makefile | 2 +- drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 + 4 files changed, 172 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c diff --git a/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt new file mode 100644 index 000..4eb39f6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt @@ -0,0 +1,32 @@ +TI CPSW ctrl macid Devicetree bindings +-- + +Required properties: + - compatible: Should be ti,am3352-cpsw-ctrl-macid this is called am3352-..., still you add it (in patch 5) to am33xx.dtsi and in the commit log you wrote about am335x. Looks abstruse. + - reg : physical base address and size of the cpsw + registers map + - reg-names : names of the register map given in reg node + - #ti,mac-address-ctrl-cells: Should be 1 Would be sensible to drop this property, or at least let it default to 1 if missing? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe 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] usb: dwc3: core: Fix gadget for system suspend/resume
During system resume, if the event buffers are not setup before
the gadget controller starts then we start with invalid context
and this can lead to bus access errors. This is especially true for
platforms that loose the controller context during system suspend.
e.g. AM437x.
The following backtrace was found when the system is suspended
and resumed with g_zero loaded on AM437x-evm (USB cable connected
to host all the while).
[ 120.981506] WARNING: CPU: 0 PID: 1656 at drivers/bus/omap_l3_noc.c:137
l3_interrupt_handler+0x198/0x28c()
[ 120.981514] L3 custom error: MASTER:USB0 WR TARGET:GPMC
[ 120.981638] Modules linked in: g_mass_storage usb_f_mass_storage
libcomposite configfs bufferclass_ti(O) omaplfb(O) cryptodev(O) dwc3
snd_soc_evm snd_soc_omap snd_pe
[ 120.981659] CPU: 0 PID: 1656 Comm: sh Tainted: G O
3.12.10-gc559824 #1
[ 120.981669] Backtrace:
[ 120.981705] [c0017880] (dump_backtrace+0x0/0x10c) from [c0017a1c]
(show_stack+0x18/0x1c)
[ 120.981730] r6:c02819ac r5:0009 r4:ec137cb8 r3:
[ 120.981767] [c0017a04] (show_stack+0x0/0x1c) from [c056c0b0]
(dump_stack+0x20/0x28)
[ 120.981802] [c056c090] (dump_stack+0x0/0x28) from [c0046d08]
(warn_slowpath_common+0x70/0x90)
[ 120.981830] [c0046c98] (warn_slowpath_common+0x0/0x90) from [c0046dcc]
(warn_slowpath_fmt+0x38/0x40)
[ 120.981856] r8:c0855eb0 r7:0002 r6:f1000700 r5:0007 r4:80080003
[ 120.981886] [c0046d94] (warn_slowpath_fmt+0x0/0x40) from [c02819ac]
(l3_interrupt_handler+0x198/0x28c)
[ 120.981900] r3:c0801ab8 r2:c06cb354
[ 120.981936] [c0281814] (l3_interrupt_handler+0x0/0x28c) from [c007162c]
(handle_irq_event_percpu+0x54/0x1b8)
[ 120.981962] [c00715d8] (handle_irq_event_percpu+0x0/0x1b8) from
[c00717c0] (handle_irq_event+0x30/0x40)
[ 120.981993] [c0071790] (handle_irq_event+0x0/0x40) from [c0074058]
(handle_fasteoi_irq+0x74/0x128)
[ 120.982006] r4:ed0056c0 r3:
[ 120.982033] [c0073fe4] (handle_fasteoi_irq+0x0/0x128) from [c0070f34]
(generic_handle_irq+0x28/0x38)
[ 120.982046] r4:002a r3:c0073fe4
[ 120.982085] [c0070f0c] (generic_handle_irq+0x0/0x38) from [c0015560]
(handle_IRQ+0x38/0x8c)
[ 120.982098] r4:c080137c r3:0182
[ 120.982124] [c0015528] (handle_IRQ+0x0/0x8c) from [c00087e0]
(gic_handle_irq+0x30/0x5c)
[ 120.982145] r6:ec137dd0 r5:c07ac480 r4:fa24010c r3:0100
[ 120.982169] [c00087b0] (gic_handle_irq+0x0/0x5c) from [c056fcc0]
(__irq_svc+0x40/0x54)
[ 120.982179] Exception stack(0xec137dd0 to 0xec137e18)
[ 120.982195] 7dc0: a1d3
0004
[ 120.982216] 7de0: a153 ec1d9010 c080de90 ec137e30 c080debc
ed756e44 ec137e2c
[ 120.982232] 7e00: ec137de0 ec137e18 bf1150e4 bf115474 6153
[ 120.982253] r7:ec137e04 r6: r5:6153 r4:bf115474
[ 120.982327] [bf115438] (dwc3_complete+0x0/0x40 [dwc3]) from [c0338f50]
(dpm_complete+0xd4/0x19c)
[ 120.982341] r5:ed756e10 r4:ed756e64
[ 120.982370] [c0338e7c] (dpm_complete+0x0/0x19c) from [c0339034]
(dpm_resume_end+0x1c/0x20)
[ 120.982400] [c0339018] (dpm_resume_end+0x0/0x20) from [c006d4ec]
(suspend_devices_and_enter+0x118/0x33c)
[ 120.982412] r4:c0833da4 r3:
[ 120.982436] [c006d3d4] (suspend_devices_and_enter+0x0/0x33c) from
[c006d928] (pm_suspend+0x218/0x254)
[ 120.982458] [c006d710] (pm_suspend+0x0/0x254) from [c006c594]
(state_store+0x70/0xc0)
[ 120.982478] r6:c057a6cc r5:c06a8320 r4:0003 r3:006d
[ 120.982515] [c006c524] (state_store+0x0/0xc0) from [c0264cc0]
(kobj_attr_store+0x1c/0x28)
[ 120.982546] [c0264ca4] (kobj_attr_store+0x0/0x28) from [c012ccb8]
(sysfs_write_file+0x170/0x1a4)
[ 120.982583] [c012cb48] (sysfs_write_file+0x0/0x1a4) from [c00d17e4]
(vfs_write+0xb8/0x190)
[ 120.982611] [c00d172c] (vfs_write+0x0/0x190) from [c00d1bf8]
(SyS_write+0x44/0x78)
[ 120.982641] [c00d1bb4] (SyS_write+0x0/0x78) from [c0014660]
(ret_fast_syscall+0x0/0x30)
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/dwc3/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d001417..0b99e3a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -824,8 +824,9 @@ static void dwc3_complete(struct device *dev)
switch (dwc-dr_mode) {
case USB_DR_MODE_PERIPHERAL:
case USB_DR_MODE_OTG:
+ dwc3_event_buffers_setup(dwc);
dwc3_gadget_complete(dwc);
- /* FALLTHROUGH */
+ break;
case USB_DR_MODE_HOST:
default:
dwc3_event_buffers_setup(dwc);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates
On 27/02/14 04:25, Mike Turquette wrote:
Quoting Tero Kristo (2014-02-14 05:45:22)
On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:
14400 - 14400
14399 - 123428571
123428572 - 123428571
123428571 - 10800
Note how clk_round_rate() returns 123428571 for rates from 123428572 to
14399, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 10800.
This means that the following code works a bit oddly:
rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);
As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 10800, not 123428571 returned by the
clk_round_rate.
This patch changes the clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:
14400 - 14400
14399 - 123428572
123428572 - 123428572
123428571 - 10800
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/clk-divider.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -24,7 +24,7 @@
* Traits of this clock:
* prepare - clk_prepare only ensures that parents are prepared
* enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * rate - rate is adjustable. clk-rate = DIV_ROUND_UP(parent-rate /
divisor)
* parent - fixed parent. No clk_set_parent support
*/
@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct
clk_hw *hw,
return parent_rate;
}
- return parent_rate / div;
+ return DIV_ROUND_UP(parent_rate, div);
}
/*
@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
}
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
MULT_ROUND_UP(rate, i));
- now = parent_rate / i;
+ now = DIV_ROUND_UP(parent_rate, i);
if (now = rate now best) {
bestdiv = i;
best = now;
@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw,
unsigned long rate,
int div;
div = clk_divider_bestdiv(hw, rate, prate);
- return *prate / div;
+ return DIV_ROUND_UP(*prate, div);
}
static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long flags = 0;
u32 val;
- div = parent_rate / rate;
+ div = DIV_ROUND_UP(parent_rate, rate);
value = _get_val(divider, div);
if (value div_mask(divider))
Basically the patch looks good to me, but it might be good to have a
testing round of sort with this. It can potentially cause regressions on
multiple boards if the drivers happen to rely on the broken clock
rates. Same for patch #2 which is a copy paste of this one, but only
impacts TI boards.
Agreed. I've taken patches #1 #2 into clk-next. Let's let them stew in
-next for a while and see if anyone's board catches on fire.
Are these on the way to 3.15?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ASoC: tlv320aic31xx: Turn power off only once.
On Mon, Mar 17, 2014 at 09:31:31AM +0200, Jyri Sarha wrote: Regulator code keep count of enables and disables. Double disable causes an ugly warning. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP5: DSS hwmod data
Hi Tomi, Thank you for the feedback. We have OMAP5 based board with no ESD Level Translator chip. So, I made a quick hack in tpd12s015 driver to skip using un-relevant GPIOs. I've copied DSS DT structure from uEmv board *.dts. However the HDMI output is not activate yet. Here is some debug output: root@cm-debian:~# dmesg | grep -i dss [0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) [0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) [0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) [0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) [0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) [0.325392] DSS: set fck to 19200 [0.325400] DSS: dss_runtime_get [0.325427] DSS: dss_restore_context [0.325445] OMAP DSS rev 6.1 [0.325450] DSS: dss_runtime_put [0.325456] DSS: dss_save_context [0.325461] DSS: context saved [0.325707] DSS: dss_restore_context [0.325711] DSS: context restored [0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 [0.325838] DSS: dss_save_context [0.325843] DSS: context saved I do not use uEvm BSP u-Boot. I'm forking from this source: git://git.denx.de/u-boot-ti.git Perhaps I'm missing some clocks initialization? What are the correct bootargs for activating HDMI video output? Thank you in advance for the assistance, Dmitry On 03/17/2014 08:13 AM, Tomi Valkeinen wrote: On 16/03/14 13:41, Dmitry Lifshitz wrote: Hi Tomi, (resending in the text format) Where can I get those unpublished omap5 and omap5-uevm display patches to test the video out with this patch? I'll appreciate your assistance in additional setup (like required uEvm .dts changes and DSI panel connection short guide). git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-pyra I've since added omap5 hdmi support, so omap5-uevm's hdmi output works on that branch. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: DSS hwmod data
On 17/03/14 15:22, Dmitry Lifshitz wrote: Hi Tomi, Thank you for the feedback. We have OMAP5 based board with no ESD Level Translator chip. So, I made a quick hack in tpd12s015 driver to skip using un-relevant GPIOs. If you don't have tpd12s015 on your board, don't modify it. Remove it from your board's dts file totally. I've copied DSS DT structure from uEmv board *.dts. However the HDMI output is not activate yet. Here is some debug output: root@cm-debian:~# dmesg | grep -i dss [0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) [0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) [0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) [0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) [0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) [0.325392] DSS: set fck to 19200 [0.325400] DSS: dss_runtime_get [0.325427] DSS: dss_restore_context [0.325445] OMAP DSS rev 6.1 [0.325450] DSS: dss_runtime_put [0.325456] DSS: dss_save_context [0.325461] DSS: context saved [0.325707] DSS: dss_restore_context [0.325711] DSS: context restored [0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 [0.325838] DSS: dss_save_context [0.325843] DSS: context saved I do not use uEvm BSP u-Boot. I'm forking from this source: git://git.denx.de/u-boot-ti.git Perhaps I'm missing some clocks initialization? What are the correct bootargs for activating HDMI video output? HDMI is the only output on the uevm, and if your board is similar, no boot args are needed. But, of course, you need omapfb or omapdrm to manage the display. Tomi signature.asc Description: OpenPGP digital signature
pandaboard boot crash with linux-next
Hi, I noticed that my omap4 panda does not boot with today's linux-next (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study it, but I didn't find any posts about the issue with a quick look. Below is the crash. Tomi [0.00] ti_dt_clocks_register: failed to lookup clock node div_ts_ck [0.00] ti_dt_clocks_register: failed to lookup clock node bandgap_ts_fclk [0.00] Unable to handle kernel NULL pointer dereference at virtual address 004c [0.00] pgd = c0004000 [0.00] [004c] *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.14.0-rc6-next-20140317-09382-g8808b950581f #104 [0.00] task: c088ddf8 ti: c0882000 task.ti: c0882000 [0.00] PC is at kernfs_find_ns+0x14/0x13c [0.00] LR is at kernfs_find_and_get_ns+0x38/0x54 [0.00] pc : [c019607c]lr : [c019628c]psr: 61d3 [0.00] sp : c0883e00 ip : c0883e30 fp : c0883e2c [0.00] r10: c0891114 r9 : ebfa11c0 r8 : ebfcd464 [0.00] r7 : r6 : r5 : c07c1814 r4 : c08e9ad8 [0.00] r3 : c08f568c r2 : r1 : c07c1814 r0 : [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 8000404a DAC: 0015 [0.00] Process swapper/0 (pid: 0, stack limit = 0xc0882248) [0.00] Stack: (0xc0883e00 to 0xc0884000) [0.00] 3e00: c08e9ad8 c07c1814 c08e9ad8 c07c1814 ebfcd464 [0.00] 3e20: c0883e4c c0883e30 c019628c c0196074 c07c1814 c07c1814 ebfcd490 [0.00] 3e40: c0883e6c c0883e50 c04c6180 c0196260 c0891140 c07c1814 ebfcd490 0001 [0.00] 3e60: c0883e9c c0883e70 c04c7308 c04c6160 c008a208 c008a130 c0883e9c [0.00] 3e80: c07c1814 c0891140 ebfcd464 a1d3 c0883ec4 c0883ea0 c04c7c9c c04c72cc [0.00] 3ea0: c0882000 ebfcd464 c074dcc8 c086bf64 0001 c074de24 c0883ee4 c0883ec8 [0.00] 3ec0: c0824b70 c04c7c14 c0891114 c0938af8 c074dcc8 c0883f54 c0883ee8 [0.00] 3ee0: c0824c58 c0824b18 c0e8bf6c c0882000 c0883f14 c0883f08 [0.00] 3f00: c05bc6b4 c05bc44c c0883f34 c0883f18 c04cca04 c05bc6b0 [0.00] 3f20: eb016b80 c0882000 c0883f4c c0883f38 c0938af8 c08910c0 c074dcc8 c074de24 [0.00] 3f40: c086ad60 c088a880 c0883f7c c0883f58 c0824f5c c0824c20 0001 c0883f68 [0.00] 3f60: 0001 c09380c0 c0882000 c0883f8c c0883f80 c0825250 c0824f1c [0.00] 3f80: c0883f9c c0883f90 c0825400 c0825238 c0883fac c0883fa0 c081d67c c08253fc [0.00] 3fa0: c0883ff4 c0883fb0 c0819a30 c081d664 c08195d0 [0.00] 3fc0: c086ad60 10c5387d c088a92c c086ad5c c088f684 8000406a [0.00] 3fe0: 412fc09a c0883ff8 80008074 c0819840 [0.00] Backtrace: [0.00] [c0196068] (kernfs_find_ns) from [c019628c] (kernfs_find_and_get_ns+0x38/0x54) [0.00] r8:ebfcd464 r7: r6: r5:c07c1814 r4:c08e9ad8 [0.00] [c0196254] (kernfs_find_and_get_ns) from [c04c6180] (safe_name+0x2c/0x98) [0.00] r7:ebfcd490 r6:c07c1814 r5: r4:c07c1814 [0.00] [c04c6154] (safe_name) from [c04c7308] (__of_add_property_sysfs+0x48/0xc4) [0.00] r7:0001 r6:ebfcd490 r5:c07c1814 r4:c0891140 [0.00] [c04c72c0] (__of_add_property_sysfs) from [c04c7c9c] (of_add_property+0x94/0xa0) [0.00] r8:a1d3 r7:ebfcd464 r6:c0891140 r5:c07c1814 r4: [0.00] [c04c7c08] (of_add_property) from [c0824b70] (omap_get_timer_dt+0x64/0x108) [0.00] r8:c074de24 r7:0001 r6:c086bf64 r5:c074dcc8 r4:ebfcd464 r3:c0882000 [0.00] [c0824b0c] (omap_get_timer_dt) from [c0824c58] (omap_dm_timer_init_one+0x44/0x2fc) [0.00] r6:c074dcc8 r5: r4:c0938af8 r3:c0891114 [0.00] [c0824c14] (omap_dm_timer_init_one) from [c0824f5c] (omap2_gp_clockevent_init+0x4c/0xd0) [0.00] r10:c088a880 r8:c086ad60 r7:c074de24 r6:c074dcc8 r5:c08910c0 r4:c0938af8 [0.00] [c0824f10] (omap2_gp_clockevent_init) from [c0825250] (omap4_sync32k_timer_init+0x24/0x60) [0.00] r7: r6:c0882000 r5:c09380c0 r4:0001 [0.00] [c082522c] (omap4_sync32k_timer_init) from [c0825400] (omap4_local_timer_init+0x10/0x68) [0.00] [c08253f0] (omap4_local_timer_init) from [c081d67c] (time_init+0x24/0x38) [0.00] [c081d658] (time_init) from [c0819a30] (start_kernel+0x1fc/0x390) [0.00] [c0819834] (start_kernel) from [80008074] (0x80008074) [0.00] r10: r9:412fc09a r8:8000406a r7:c088f684 r6:c086ad5c r5:c088a92c [0.00] r4:10c5387d [0.00] Code: e92dd9f0 e24cb004 e24dd00c e59f3104 (e1d084bc) [0.00] ---[ end trace
Re: [GIT PULL 1/2] omap device tree changes for v3.15, part 3
On Thursday 13 March 2014, Tony Lindgren wrote: Hi, Resending these two, looks like my updated scripts have some issues hitting the mailing lists.. The following changes since commit 18c49af3ee9e32a535413a949672bea726699f04: ARM: dts: am335x-evmsk: enable dual_emac mode (2014-03-05 11:53:36 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.15/dt-part3 for you to fetch changes up to e1902bbe44844597a38c8cbae30ca895f6e126ee: ARM: dts: Add MMC2/SDIO/WLAN support for cm-t3530 (2014-03-12 10:40:37 -0700) Device tree related changes to the omap iommu driver as that is finally getting updated. Also few trivial board related .dts updates to add more devices. Pulled into next/dt, thanks! I haven't really been following the iommu discussions, so I have to trust you are doing the right thing here. What is the status on iommu support through DT? Do we have or require a generic binding for iommus? Are you following that, or will you have to do incompatible changes to do that? 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
Re: [GIT PULL 2/2] omap overo related device tree changes for v3.15
On Thursday 13 March 2014, Tony Lindgren wrote:
The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691:
Linux 3.14-rc4 (2014-02-23 17:40:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.15/dt-overo-signed
for you to fetch changes up to 28b191118c11719bb27db621425a70be28a40e08:
ARM: dts: Add support for the Overo Summit (2014-03-12 10:21:16 -0700)
Updates to the .dts files to support more Gumstix boards.
These are sent separately from the rest of the .dts changes
as these depend on the fixes merged into v3.14-rc4, and
needed a bit more time to get updated on the fixes.
Pulled into next/dt, thanks!
I had a trivial merge conflict in omap3-overo.dtsi that I resolved as below.
Arnd
diff --cc arch/arm/boot/dts/omap3-overo.dtsi
index b08142f,c37b130..69ca7c4
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@@ -91,11 -33,3 +33,6 @@@
};
};
- uart3 {
- pinctrl-names = default;
- pinctrl-0 = uart3_pins;
- };
-
+mcbsp2 {
+ status = okay;
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: DSS hwmod data
Hi Tomi, Unfortunately, I have a lack of experience with DT DSS stuff. How should I define the endpoints and the connector in my case? Please, could you provide some reference. Regarding omapfb, is it sufficient to turn it on in the Kernel config? Thanks, Dmitry On 03/17/2014 03:28 PM, Tomi Valkeinen wrote: On 17/03/14 15:22, Dmitry Lifshitz wrote: Hi Tomi, Thank you for the feedback. We have OMAP5 based board with no ESD Level Translator chip. So, I made a quick hack in tpd12s015 driver to skip using un-relevant GPIOs. If you don't have tpd12s015 on your board, don't modify it. Remove it from your board's dts file totally. I've copied DSS DT structure from uEmv board *.dts. However the HDMI output is not activate yet. Here is some debug output: root@cm-debian:~# dmesg | grep -i dss [0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) [0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) [0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) [0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) [0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) [0.325392] DSS: set fck to 19200 [0.325400] DSS: dss_runtime_get [0.325427] DSS: dss_restore_context [0.325445] OMAP DSS rev 6.1 [0.325450] DSS: dss_runtime_put [0.325456] DSS: dss_save_context [0.325461] DSS: context saved [0.325707] DSS: dss_restore_context [0.325711] DSS: context restored [0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 [0.325838] DSS: dss_save_context [0.325843] DSS: context saved I do not use uEvm BSP u-Boot. I'm forking from this source: git://git.denx.de/u-boot-ti.git Perhaps I'm missing some clocks initialization? What are the correct bootargs for activating HDMI video output? HDMI is the only output on the uevm, and if your board is similar, no boot args are needed. But, of course, you need omapfb or omapdrm to manage the display. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, On Sat, Mar 15, 2014 at 1:58 AM, Suman Anna s-a...@ti.com wrote: The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. I might be missing something, but why can't we have the specifier+base_id be the hwlock id and then we can entirely drop most of the core changes in this patch-set? I realize we couldn't easily support sparse id numbers, but not sure this is relevant to hwspinlocks? do we have a use case that couldn't be supported in this case? I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. How could drivers know what the base_id is if DT doesn't provide it? please note that we can't depend on order of controller probing; the hwlock id numbers cannot depend on implementation details. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe 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 2/9] opp-modifier: Add opp-modifier-reg driver
On 03/14/2014 04:00 PM, Rob Herring wrote: On Fri, Mar 14, 2014 at 2:25 PM, Dave Gerlach d-gerl...@ti.com wrote: Driver to read from a register and depending on either set bits or a specific known selectively enable or disable OPPs based on DT node. Can support opp-modifier-reg-bit where single bits within the register determine the availability of an OPP or opp-modifier-reg-val where a certain value inside the register or a portion of it determine what the maximum allowed OPP is. The driver expects a device that has already has its OPPs loaded and then will disable the OPPs not matching the criteria specified in the opp-modifier table. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- .../devicetree/bindings/power/opp-modifier.txt | 111 + drivers/power/opp/Makefile | 1 + drivers/power/opp/opp-modifier-reg.c | 259 + 3 files changed, 371 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt create mode 100644 drivers/power/opp/opp-modifier-reg.c diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt b/Documentation/devicetree/bindings/power/opp-modifier.txt new file mode 100644 index 000..af8a2e9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/opp-modifier.txt @@ -0,0 +1,111 @@ +* OPP-Modifier - opp modifier to selectively enable operating points + +Many SoCs that have selectively modifiable OPPs can specify +all available OPPs in their operating-points listing and then define +opp_modifiers to enable or disable the OPPs that are actually available +on the specific hardware. + +* OPP Modifier Provider Uggg. Please stop designing around the current OPP binding which has the problem that the OPP table is not extensible to add more data. Define a new OPP binding that solves these problems. This is at least Generically, there are three different issues with current OPP bindings: a) ability to enable disable certain OPPs depending on SoC OTP/Efuse settings. b) ability to reuse OPPs defined for one device node for another (cpu1 to reuse OPP definitions of cpu0) c) ability to add additional information per OPP. we can argue this is a superset of (a), but really, the problems are different. Previous proposals include making each OPP as a phandle, but there does not seem much traction in that direction either. - proposal here has nothing to do with (b) or (c). the 3rd OPP related binding addition I've seen recently. But I wouldn't spend a lot of effort on a new OPP binding just to add the functionality you are adding here because I don't like the whole concept in general. This might be a common way to determine valid OPPs on TI chips, but I think it is too low level and I don't want to see Not just TI chips, but iMX, now, Marvell, Xilinx as well. potentially more as well. doing OTP/Efuse based decision on which OPPs are valid on a chip is not a TI specific thing. This was the reason for us to try to define something generic enough to be reused by more SoCs than just TI. bindings for every different possible way. Just add platform code to do the OPP setup you need. Errr.. adding platform code means the hardware description goes back to kernel. is'nt that giving up on device tree binding for describing hardware? Frankly, I prefer the bootloader/firmware fixup the OPP table approach mentioned in the cpufreq-cpu0 thread. Somewhat less desirable, but the kernel could do the fixups as well (via of_update_property). a) Trying to move the hardware definition away from device tree seems to me a major step backwards. b) Allowing for definitions in platform code is a step backwards again for a generic solution that works for more than 1 vendor. c) moving the logic away to bootloader when it can easily be done in kernel again is adding burden to bootloader for data it does need to handle. OPP is a hardware behavior, which OPPs are enabled are described in hardware on certain SoCs. the current proposal is to provide a generic solution for those devices that allow for dynamic definition of OPPs based on SoC efuse definition. -- 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: [GIT PULL] omap fixes for v3.15 merge window
On Thursday 13 March 2014, Tony Lindgren wrote: The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691: Linux 3.14-rc4 (2014-02-23 17:40:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.15/fixes-for-merge-window for you to fetch changes up to 77319669af37a1cfc844b801e83343b37e3c7e13: ARM: OMAP4: hwmod data: correct the idlemodes for spinlock (2014-03-13 14:09:57 -0700) Fixes for omaps that would be good to get in before v3.15-rc1. Merged into next/fixes-non-critical, thanks! 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
Re: [GIT PULL 1/2] omap device tree changes for v3.15, part 3
* Arnd Bergmann a...@arndb.de [140317 07:18]:
On Thursday 13 March 2014, Tony Lindgren wrote:
Hi,
Resending these two, looks like my updated scripts have some issues hitting
the mailing lists..
The following changes since commit 18c49af3ee9e32a535413a949672bea726699f04:
ARM: dts: am335x-evmsk: enable dual_emac mode (2014-03-05 11:53:36 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.15/dt-part3
for you to fetch changes up to e1902bbe44844597a38c8cbae30ca895f6e126ee:
ARM: dts: Add MMC2/SDIO/WLAN support for cm-t3530 (2014-03-12 10:40:37
-0700)
Device tree related changes to the omap iommu driver as that
is finally getting updated. Also few trivial board related
.dts updates to add more devices.
Pulled into next/dt, thanks!
Thanks, looks like the merge ddf071148934047b1e87bf89e823e74f267f0b84
introduces a build failure though:
@@@ -22,8 -23,7 +23,7 @@@
#include common-board-devices.h
#include dss-common.h
#include control.h
- #include omap-secure.h
-#include omap_device.h
+#include soc.h
struct pdata_init {
const char *compatible;
Those need to be added back to keep things building.
I haven't really been following the iommu discussions, so I have to trust
you are doing the right thing here. What is the status on iommu
support through DT? Do we have or require a generic binding for iommus?
There are certainly various things that could be improved in the
drivers/iommu, just doing grep EXPORT_SYMBOL drivers/iommu shows quite
a few things that should probably be implemented in a generic way.
Currently the bindings don't do much, but could probably be simplified
further. Things like ti,#tlb-entries and ti,iommu-bus-err-back may not
even be needed and could be set by the driver match .data based on the
compatible flag alone.
This set contains the independent SoC related changes related to get
things moving for the drivers/iommu changes as discussed here:
http://www.spinics.net/lists/arm-kernel/msg312144.html
Some things like reset are still being done using platform_data with
a promise of future patches:
http://www.spinics.net/lists/linux-omap/msg104328.html
Are you following that, or will you have to do incompatible changes to
do that?
I'm not following too closely on the drivers/iommu parts, mostly
following just the moving away from platform data part at this point.
Suman can probably describe what needs to be done more accurately.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] omap overo related device tree changes for v3.15
* Arnd Bergmann a...@arndb.de [140317 07:22]:
On Thursday 13 March 2014, Tony Lindgren wrote:
The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691:
Linux 3.14-rc4 (2014-02-23 17:40:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.15/dt-overo-signed
for you to fetch changes up to 28b191118c11719bb27db621425a70be28a40e08:
ARM: dts: Add support for the Overo Summit (2014-03-12 10:21:16 -0700)
Updates to the .dts files to support more Gumstix boards.
These are sent separately from the rest of the .dts changes
as these depend on the fixes merged into v3.14-rc4, and
needed a bit more time to get updated on the fixes.
Pulled into next/dt, thanks!
I had a trivial merge conflict in omap3-overo.dtsi that I resolved as below.
Arnd
diff --cc arch/arm/boot/dts/omap3-overo.dtsi
index b08142f,c37b130..69ca7c4
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@@ -91,11 -33,3 +33,6 @@@
};
};
- uart3 {
- pinctrl-names = default;
- pinctrl-0 = uart3_pins;
- };
-
+mcbsp2 {
+ status = okay;
+};
Looks good to me thanks, and looks like I merged it wrong in
my omap-for-v3.15/tmp-merge as mcbsp2 is not defined in
omap3-overo-common-peripherals.dtsi.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] net: cpsw: Add control-module macid driver
Hi, * Markus Pargmann m...@pengutronix.de [140315 06:12]: This driver extracts the hardware macid from the control module of am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw to get the macid from within the processor. Few things have improved recently :) This can be now implemented in a much cleaner way using regmap against the already defined syscon node. For an example, see how the MMC PBIAS regulator is using regmap in Linux next: 11469e0bb1 (regulator: add pbias regulator support) cd042fe5c1 (ARM: dts: add pbias dt node) That avoids the problem of the tinkering with SoC specific registers that belong to another device. So please update this series for regmap, let's not add more mapping of system control module registers to the drivers. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/9] opp-modifier: Add opp-modifier-reg driver
On Mon, Mar 17, 2014 at 9:30 AM, Nishanth Menon n...@ti.com wrote: On 03/14/2014 04:00 PM, Rob Herring wrote: On Fri, Mar 14, 2014 at 2:25 PM, Dave Gerlach d-gerl...@ti.com wrote: Driver to read from a register and depending on either set bits or a specific known selectively enable or disable OPPs based on DT node. Can support opp-modifier-reg-bit where single bits within the register determine the availability of an OPP or opp-modifier-reg-val where a certain value inside the register or a portion of it determine what the maximum allowed OPP is. The driver expects a device that has already has its OPPs loaded and then will disable the OPPs not matching the criteria specified in the opp-modifier table. Signed-off-by: Dave Gerlach d-gerl...@ti.com --- .../devicetree/bindings/power/opp-modifier.txt | 111 + drivers/power/opp/Makefile | 1 + drivers/power/opp/opp-modifier-reg.c | 259 + 3 files changed, 371 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt create mode 100644 drivers/power/opp/opp-modifier-reg.c diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt b/Documentation/devicetree/bindings/power/opp-modifier.txt new file mode 100644 index 000..af8a2e9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/opp-modifier.txt @@ -0,0 +1,111 @@ +* OPP-Modifier - opp modifier to selectively enable operating points + +Many SoCs that have selectively modifiable OPPs can specify +all available OPPs in their operating-points listing and then define +opp_modifiers to enable or disable the OPPs that are actually available +on the specific hardware. + +* OPP Modifier Provider Uggg. Please stop designing around the current OPP binding which has the problem that the OPP table is not extensible to add more data. Define a new OPP binding that solves these problems. This is at least Generically, there are three different issues with current OPP bindings: a) ability to enable disable certain OPPs depending on SoC OTP/Efuse settings. More generically: ...depending on variety of factors. b) ability to reuse OPPs defined for one device node for another (cpu1 to reuse OPP definitions of cpu0) c) ability to add additional information per OPP. we can argue this is a superset of (a), but really, the problems are different. It is all additional data per OPP. Additional different information is of course for different problems. That doesn't mean we need different solutions. Previous proposals include making each OPP as a phandle, but there does not seem much traction in that direction either. - proposal here has nothing to do with (b) or (c). They may have nothing to do with each other, but they all have to do with the OPP binding. If we're going to change/extend the binding, then all issues need to be taken into account. the 3rd OPP related binding addition I've seen recently. But I wouldn't spend a lot of effort on a new OPP binding just to add the functionality you are adding here because I don't like the whole concept in general. This might be a common way to determine valid OPPs on TI chips, but I think it is too low level and I don't want to see Not just TI chips, but iMX, now, Marvell, Xilinx as well. potentially more as well. doing OTP/Efuse based decision on which OPPs are valid on a chip is not a TI specific thing. This was the reason for us to try to define something generic enough to be reused by more SoCs than just TI. Agreed, but I'm not convinced how different SOCs determine valid OPPs is common enough. Certainly how to mark an entry disabled is common though. bindings for every different possible way. Just add platform code to do the OPP setup you need. Errr.. adding platform code means the hardware description goes back to kernel. is'nt that giving up on device tree binding for describing hardware? We're always going to have some platform code. I'm not saying you have to in this case. I'm saying either come up with an OPP binding addressing all these issues or live with the existing one and fix it up in the kernel or bootloader. Frankly, I prefer the bootloader/firmware fixup the OPP table approach mentioned in the cpufreq-cpu0 thread. Somewhat less desirable, but the kernel could do the fixups as well (via of_update_property). a) Trying to move the hardware definition away from device tree seems to me a major step backwards. b) Allowing for definitions in platform code is a step backwards again for a generic solution that works for more than 1 vendor. c) moving the logic away to bootloader when it can easily be done in kernel again is adding burden to bootloader for data it does need to handle. The burden has to be somewhere. Maintaining a binding forever in the kernel is a burden as well if it is poorly designed. Valid OPPs are not going to just be random. There's probably on a
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/17/2014 09:23 AM, Ohad Ben-Cohen wrote: Hi Suman, On Sat, Mar 15, 2014 at 1:58 AM, Suman Anna s-a...@ti.com wrote: The series doesn't change the semantics of hwspinlock registration or adds a new OF controller registration function. Implementations would still need to register a controller using a base_id and number of locks. The series rather adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and there are no restrictions on the args specifier being relative id numbers. Though this is what the simple default xlate helper does (most common usage), the added xlate ops and #hwlock-cells should allow individual implementation drivers to adjust any variations, and return a relative lock w.r.t its registered base_id, as this is how a lock gets registered in the first place. I might be missing something, but why can't we have the specifier+base_id be the hwlock id and then we can entirely drop most of the core changes in this patch-set? base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Please see the comments from Mark regarding the same on an earlier version. http://marc.info/?l=linux-omapm=138135487703774w=2 I realize we couldn't easily support sparse id numbers, but not sure this is relevant to hwspinlocks? do we have a use case that couldn't be supported in this case? I agree on the sparse id numbers on hwspinlock, I don't see a need for it. I actually started out this series with the base_id property, and dropped it in v3 based on comments looking at it from the request-specific-lock semantics with DT. That said, the drivers still need to manage a 'base_id' needed for registration when they get probed for multiple controllers. Getting the base_id from DT _may_ be useful just for registration purposes, but for requesting a hwlock, a controller phandle and an implementation defined args-specifier should suffice IMHO. How could drivers know what the base_id is if DT doesn't provide it? please note that we can't depend on order of controller probing; the hwlock id numbers cannot depend on implementation details. Yes, I agree this is an issue if we have to have the base_ids fixed per controller. But I don't think it makes any difference from requesting a lock from a client DTS node. I can bring it back if Mark agrees. The exact notion of informing the hwspinlock core about a list of reserved locks is missing at the moment (even in the non-DT case). I am not sure if this got lost during the conversion of the registration from per lock to registering a bank of locks together, or if it is implied by the base_id + num_locks combination. The core today supports requesting only those locks that were actually registered, whether allocating a free one dynamically or giving a specific one. Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. Also mandates that unique locks were requested for different clients (left to board integration). The early board code also has to pass on the reserved hwspinlock information to the actual client driver somehow (platform data). With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API
Hi Santosh,
On 03/15/2014 12:54 PM, Santosh Shilimkar wrote:
On Friday 14 March 2014 09:49 PM, Suman Anna wrote:
Hi Santosh, Laurent, Russell, Arnd,
On 03/14/2014 12:51 PM, Santosh Shilimkar wrote:
On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
Hi Santosh,
On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
+ Russell, Arnd
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management manually
(and ignoring L2 cache), use clean_dcache_area() to make sure the
entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been some
previous attempts at this as well by Ramesh Gupta, with the last thread
(a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++-
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
*H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
-/* FIXME: L2 cache should be taken care of if it exists */
-do {
-asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
-: : r (first));
-first += L1_CACHE_BYTES / sizeof(*first);
-} while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
-/* FIXME: L2 cache should be taken care of if it exists */
-do {
-asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
-: : r (first));
-first += L1_CACHE_BYTES / sizeof(*first);
-} while (first = last);
+clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
So this particular change has a long history (have to dig through to educate
myself). I have not seen clean_dcache_area attempted before, and I wasn't sure
myself it it can be used here. Ramesh and Fernando definitely did start out
with dmac_flush_range and outer_flush_range which was definitely nacked [1].
OK. Please wrap the lines appropriately while replying.
Hmm, weird. I don't see this with my other responses. But sorry for
the trouble.
Please note that the omap-iommu driver already uses clean_dcache_area().
That's where I got the idea :-)
So that fall through the cracks then ;-)
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
I can replace clean_dcache_area() with dma_map_page() as done by the arm-smmu
driver. If that's fine I'll modify this patch accordingly in v2.
Ramesh had also attempted to use dma_page_single() previously [2], and Russell
has instead suggested to extend the cpu cache operations [3].
Ramesh had worked based on this suggestion and the series reached v6 [4] (same
as link I mentioned above) and this is the last attempt on this, but the thread
went silent.
I am wondering if that is still valid and is the right way to go, as this seems
to be a common problem. I do see dmac_flush_range being used for similar
purposes in msm_iommu.c and exynos-iommu.c, so looks like they also fell
through the cracks.
Thanks for the links. I think you should revive the v6 series unless and until
RMK has some other suggestion. This can also help to remove the wrong usages
from other IOMMU drivers as you pointed out.
OK, will do.
regards
Suman
Laurent,
Can you drop this patch out from v2 so that it is not clubbed with the small
cleanup patches, and we can track this separately?
Agree
Regards,
Santosh
[1] http://marc.info/?l=linux-omapm=129907009019355w=2
[2] http://marc.info/?t=13028180495r=1w=2
[3] http://marc.info/?l=linux-omapm=131310179423214w=2
[4] http://marc.info/?t=13475203541r=1w=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: [PATCHv4 0/7] omap hwspinlock dt support
Hi Suman, On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna s-a...@ti.com wrote: base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Do you mean hwspin_lock_get_id() will return just the specifier instead of base_id+specifier? This is problematic, because Linux will not be able to communicate this lock id outside to a different core running a different OS: that OS will have no idea what hwlock controller this is relative to. Please see the comments from Mark regarding the same on an earlier version. I think I understand and agree with Mark generally, but in this case, the hwlock id is not an implementation detail. Unlike GPIOs/DMAs, this id number is global and system-wide (Linux is just one component in the system, and must use the same predefined id numbers all other cores use, otherwise it will be impossible to use those hwlocks for multi-core synchronization). Yes, I agree this is an issue if we have to have the base_ids fixed per controller. Do you see any other way this could work if the base_ids were not predefined? Linux and some other core running a different OS must agree on the id numbers of the hardware locks we have in the system. Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. I don't think so, you could request a specific lock by id number. With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. Exactly. The platform-specific hwspinlock driver will have to inform the core, upon registration, which of the locks are already reserved. In turn, the core will never provide them to clients that dynamically allocate an hwlock: they will be provided only to clients that ask for them specifically (using phandle+specifier). Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Laurent, Sakari, On 03/16/2014 04:54 PM, Sakari Ailus wrote: Hi Laurent and Suman, On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Hi Suman, (CC'ing Joerg Roedel and Marek Szyprowski for the core IOMMU discussion) On Thursday 13 March 2014 21:33:37 Suman Anna wrote: On 03/07/2014 06:46 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 5/5, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I'd like to take this as an opportunity to discuss OMAP IOMMU integration with the ARM DMA mapping implementation. The idea is to hide the IOMMU completely behind the DMA mapping API, making it completely transparent to drivers. Thanks for starting the discussion. A drivers will only need to allocate memory with dma_alloc_*, and behind the scene the ARM DMA mapping implementation will find out that the device is behind an IOMMU and will map the buffers through the IOMMU, returning an I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to the IOMMU core should be necessary anymore. To use the IOMMU the ARM DMA implementation requires a VA mapping to be created with a call to arm_iommu_create_mapping() and to then be attached to the device with arm_iommu_attach_device(). This is currently not performed by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP driver for now. I believe this to still be an improvement compared to the current situation, as it allows getting rid of custom memory allocation code in the OMAP3 ISP driver and custom I/O VA space management in omap-iovmm. However, that code should ideally be removed from the driver. The question is, where should it be moved to ? One possible solution would be to add the code to the OMAP IOMMU driver. However, this would require all OMAP IOMMU users to be converted to the ARM DMA API. I assume there would be issues that I don't foresee though. Yeah, I think this will pose some problems for the other main user of IOMMUs - the remoteproc devices (DSP, Dual-Cortex M3/M4 processors in OMAP4 and beyond). A remoteproc device also needs to map memory at specific addresses for its code and data sections, and not rely on a I/O VA address being given to it. The firmware sections are already linked at specific addresses, and so remoteproc needs to allocate memory, load the firmware and map into appropriate device addresses. We are doing this currently usage a combination of CMA memory to get contiguous memory (there are some restrictions for certain sections) and iommu_map/unmap API to program the MMU with these pages. This usage is different from what is expected from exchanging buffers, which can be allocated from a predefined mapping range. Even that one is tricky if we need to support different cache properties/attributes as the cache configuration is in general local to these processors. Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. Actually, I think there is one another use case, even with remoteprocs which is to runtime map buffers. This is different from the firmware management. The memory for buffers could have been allocated from other subsystems, but remoteproc would need just to manage the VA space and map. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed? Can this be done through iommu_domain_set_attr? But that means the client driver has to dictate this. The iommu driver can be configured appropriately based on this. The driver would need to know that, I think. Currently the DMA mapping API doesn't allow explicit addressing to IOVA address space AFAIK. The IOMMU API does. It's a good question how to do this as I don't think there's even a way for the driver to explicitly obtain access to the IOMMU. The virtual address space allocation would need to take into account that some of the address space is actually mapped outside it. The iova library can do this already. I'm not even sure whether the OMAP IOMMU driver would be the best place to put that code. Ideally VA spaces should be created by the platform somehow, and mapping of devices to IOMMUs should be handled by the IOMMU core instead of the IOMMU drivers. We're not there yet, and the path might not
Re: [GIT PULL 1/2] omap device tree changes for v3.15, part 3
Hi Arnd, Tony,
On 03/17/2014 11:45 AM, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140317 07:18]:
On Thursday 13 March 2014, Tony Lindgren wrote:
Hi,
Resending these two, looks like my updated scripts have some issues hitting
the mailing lists..
The following changes since commit 18c49af3ee9e32a535413a949672bea726699f04:
ARM: dts: am335x-evmsk: enable dual_emac mode (2014-03-05 11:53:36 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.15/dt-part3
for you to fetch changes up to e1902bbe44844597a38c8cbae30ca895f6e126ee:
ARM: dts: Add MMC2/SDIO/WLAN support for cm-t3530 (2014-03-12 10:40:37 -0700)
Device tree related changes to the omap iommu driver as that
is finally getting updated. Also few trivial board related
.dts updates to add more devices.
Pulled into next/dt, thanks!
Thanks, looks like the merge ddf071148934047b1e87bf89e823e74f267f0b84
introduces a build failure though:
@@@ -22,8 -23,7 +23,7 @@@
#include common-board-devices.h
#include dss-common.h
#include control.h
- #include omap-secure.h
-#include omap_device.h
+#include soc.h
struct pdata_init {
const char *compatible;
Those need to be added back to keep things building.
I haven't really been following the iommu discussions, so I have to trust
you are doing the right thing here. What is the status on iommu
support through DT? Do we have or require a generic binding for iommus?
There are certainly various things that could be improved in the
drivers/iommu, just doing grep EXPORT_SYMBOL drivers/iommu shows quite
a few things that should probably be implemented in a generic way.
Yes, Laurent is working towards removing omap-iovmm.c completely and
started a discussion/cleanup series towards thats[1]. I expect some of
the other export symbols for OMAP to also vanish slowly once iovmm is
removed.
Currently the bindings don't do much, but could probably be simplified
further. Things like ti,#tlb-entries and ti,iommu-bus-err-back may not
even be needed and could be set by the driver match .data based on the
compatible flag alone.
Yeah, I was in fact looking for feedback on exactly these properties
[2]. I haven't removed this as the only feedback I got was positive for
the changes [3].
This set contains the independent SoC related changes related to get
things moving for the drivers/iommu changes as discussed here:
http://www.spinics.net/lists/arm-kernel/msg312144.html
Some things like reset are still being done using platform_data with
a promise of future patches:
http://www.spinics.net/lists/linux-omap/msg104328.html
Are you following that, or will you have to do incompatible changes to
do that?
I'm not following too closely on the drivers/iommu parts, mostly
following just the moving away from platform data part at this point.
Suman can probably describe what needs to be done more accurately.
I am not expecting any changes to bindings as this series is mainly
adding the OMAP iommu DT nodes and having the OMAP IOMMU driver
functional with the DT-based IOMMU devices. We are yet to add any DTS
client devices use IOMMU.
regards
Suman
[1] http://marc.info/?l=linux-omapm=139423949120188w=2
[2] http://marc.info/?l=linux-omapm=139231544416973w=2
[3] http://marc.info/?l=linux-omapm=139338074931831w=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 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Suman and Sakari, On Monday 17 March 2014 14:58:24 Suman Anna wrote: On 03/16/2014 04:54 PM, Sakari Ailus wrote: On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Hi Suman, (CC'ing Joerg Roedel and Marek Szyprowski for the core IOMMU discussion) On Thursday 13 March 2014 21:33:37 Suman Anna wrote: On 03/07/2014 06:46 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. The biggest issue is fixed by patch 5/5, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I'd like to take this as an opportunity to discuss OMAP IOMMU integration with the ARM DMA mapping implementation. The idea is to hide the IOMMU completely behind the DMA mapping API, making it completely transparent to drivers. Thanks for starting the discussion. A drivers will only need to allocate memory with dma_alloc_*, and behind the scene the ARM DMA mapping implementation will find out that the device is behind an IOMMU and will map the buffers through the IOMMU, returning an I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to the IOMMU core should be necessary anymore. To use the IOMMU the ARM DMA implementation requires a VA mapping to be created with a call to arm_iommu_create_mapping() and to then be attached to the device with arm_iommu_attach_device(). This is currently not performed by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP driver for now. I believe this to still be an improvement compared to the current situation, as it allows getting rid of custom memory allocation code in the OMAP3 ISP driver and custom I/O VA space management in omap-iovmm. However, that code should ideally be removed from the driver. The question is, where should it be moved to ? One possible solution would be to add the code to the OMAP IOMMU driver. However, this would require all OMAP IOMMU users to be converted to the ARM DMA API. I assume there would be issues that I don't foresee though. Yeah, I think this will pose some problems for the other main user of IOMMUs - the remoteproc devices (DSP, Dual-Cortex M3/M4 processors in OMAP4 and beyond). A remoteproc device also needs to map memory at specific addresses for its code and data sections, and not rely on a I/O VA address being given to it. The firmware sections are already linked at specific addresses, and so remoteproc needs to allocate memory, load the firmware and map into appropriate device addresses. We are doing this currently usage a combination of CMA memory to get contiguous memory (there are some restrictions for certain sections) and iommu_map/unmap API to program the MMU with these pages. This usage is different from what is expected from exchanging buffers, which can be allocated from a predefined mapping range. Even that one is tricky if we need to support different cache properties/attributes as the cache configuration is in general local to these processors. Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. Actually, I think there is one another use case, even with remoteprocs which is to runtime map buffers. This is different from the firmware management. The memory for buffers could have been allocated from other subsystems, but remoteproc would need just to manage the VA space and map. Right, although you might not always have to manage the VA space in that case. Anyway, if your driver needs to manage the VA space for the firmware, it should be able to manage the VA space for the buffers using the same IOMMU API. The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed? Can this be done through iommu_domain_set_attr? But that means the client driver has to dictate this. The iommu driver can be configured appropriately based on this. The problem with that approach is that IOMMU client (bus master) drivers would need a pointer to the IOMMU domain. That's what we want to avoid in the first place :-) The driver would need to know that, I think. The IOMMU client driver would know that. Or, to be accurate, it should either know that it wants to manage the IOMMU directly, or should ignore
Re: [PATCH 1/5] iommu/omap: Use the cache cleaning API
Hi all,
On Friday 14 March 2014 20:49:56 Suman Anna wrote:
On 03/14/2014 12:51 PM, Santosh Shilimkar wrote:
On Friday 14 March 2014 12:38 PM, Laurent Pinchart wrote:
On Friday 14 March 2014 12:15:11 Santosh Shilimkar wrote:
On Thursday 13 March 2014 10:47 PM, Anna, Suman wrote:
On 03/07/2014 06:46 PM, Laurent Pinchart wrote:
The page table entries must be cleaned from the cache before being
accessed by the IOMMU. Instead of implementing cache management
manually (and ignoring L2 cache), use clean_dcache_area() to make sure
the entries are visible to the device.
Thanks for fixing this, this has been long pending. There have been
some previous attempts at this as well by Ramesh Gupta, with the last
thread (a long time now) being
http://marc.info/?t=13475203541r=1w=2
Santosh,
Can you please take a look at this patch and provide your comments?
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 41 ++---
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index a893eca..bb605c9 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -500,24 +500,9 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
/*
* H/W pagetable operations
*/
-static void flush_iopgd_range(u32 *first, u32 *last)
+static void flush_pgtable(void *addr, size_t size)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ clean_dcache_area(addr, size);
I remember NAKing this approach in past and my stand remains same.
The cache APIs which you are trying to use here are not suppose
to be used outside.
So this particular change has a long history (have to dig through to educate
myself).
Thank you for doing so, the result is pretty informative.
I have not seen clean_dcache_area attempted before, and I wasn't sure myself
it it can be used here. Ramesh and Fernando definitely did start out with
dmac_flush_range and outer_flush_range which was definitely nacked [1].
Please note that the omap-iommu driver already uses clean_dcache_area().
That's where I got the idea :-)
So that fall through the cracks then ;-)
I think the right way to fix this is to make use of streaming APIs.
If needed, IOMMU can have its own dma_ops for special case
handling if any.
I can replace clean_dcache_area() with dma_map_page() as done by the
arm-smmu driver. If that's fine I'll modify this patch accordingly in
v2.
Ramesh had also attempted to use dma_page_single() previously [2], and
Russell has instead suggested to extend the cpu cache operations [3].
Ramesh had worked based on this suggestion and the series reached v6 [4]
(same as link I mentioned above) and this is the last attempt on this,
but the thread went silent.
I'm not sure yet whether I totally agree with Russell here, not on the
rationale of his opinion, but on what we're trying to achieve. Isn't the IOMMU
just a device that can perform direct memory access to fetch page table
entries ? It seems to me that what the driver needs is to make sure that
changes to the page tables are visible to the device when performing direct
memory access. That doesn't really differ from other DMA use cases, so why
would it need an IOMMU-specific API ? Or does the OMAP IOMMU fetch page table
entries using a special kind of DMA ?
I am wondering if that is still valid and is the right way to go, as this
seems to be a common problem. I do see dmac_flush_range being used for
similar purposes in msm_iommu.c and exynos-iommu.c, so looks like they also
fell through the cracks.
Laurent,
Can you drop this patch out from v2 so that it is not clubbed with the small
cleanup patches, and we can track this separately?
Sure, I'll do that.
[1] http://marc.info/?l=linux-omapm=129907009019355w=2
[2] http://marc.info/?t=13028180495r=1w=2
[3] http://marc.info/?l=linux-omapm=131310179423214w=2
[4] http://marc.info/?t=13475203541r=1w=2
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe 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/5] iommu/omap: Use the cache cleaning API
Hi Arnd, On Friday 14 March 2014 17:57:48 Arnd Bergmann wrote: On Friday 14 March 2014, Santosh Shilimkar wrote: I remember NAKing this approach in past and my stand remains same. The cache APIs which you are trying to use here are not suppose to be used outside. I think the right way to fix this is to make use of streaming APIs. If needed, IOMMU can have its own dma_ops for special case handling if any. Russell, Arnd might have more ideas. I have a bad feeling about using the dma-mapping API within the IOMMU code, because that driver is also used to implement the dma-mapping API for devices attached to the IOMMU. It's possible that it just works. Right, but I hope the memory port used by the IOMMU to fetch page table entries will not go through itself the same IOMMU :-) Is the IOMMU actually designed to have page tables in noncoherent memory? I would have expected that the iopt accesses must all be done on dma_alloc_coherent() provided memory to guarantee proper accesses. I'm not knowledgeable enough about the OMAP IOMMU, but at least the Renesas IOMMU doesn't need coherent memory as long as the driver makes sure that changes to the page tables are made visible to the device. That IOMMU can also use the DVM hardware coherency protocols on a cache coherent interconnect, but I haven't investigated that yet. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4 SDP regression...
There's been a couple of regressions on OMAP4430 SDP I've only recently noticed: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=1597 Configuring network interfaces... udhcpc (v1.9.1) started Sending discover... Sending discover... Sending discover... No lease, failing done. No link lights come up either. The hardware is fine because uboot manages to successfully tftp the kernel. It looks like it was working in -rc4+armsoc and -rc5+armsoc, but not -rc6+armsoc. From what I can see, nothing has changed in drivers/net/ethernet/micrel/ since rc5. I've been through the delta from 3.14-rc5, and I don't see anything obvious. Any ideas? Known problem? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/7] omap hwspinlock dt support
Hi Ohad, On 03/17/2014 02:47 PM, Ohad Ben-Cohen wrote: Hi Suman, On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna s-a...@ti.com wrote: base_id would be a property (if added) of the hwspinlock controller node, and from DT perspective, we will be using the phandle for the controller anyway. So, using a base_id+specifier seems redundant, as the specifier is already w.r.t a hwspinlock controller node. It is best to leave the base_id out, just use the specifier. This is pretty much the standard practice (GPIOs, DMAs, etc all follow this). Do you mean hwspin_lock_get_id() will return just the specifier instead of base_id+specifier? This is problematic, because Linux will not be able to communicate this lock id outside to a different core running a different OS: that OS will have no idea what hwlock controller this is relative to. The behavior of hwspin_lock_get_id() is unchanged, so you will still get the global lock id back. The hwspin_lock_request_specific() (note: not the OF one) will also still be operating on the global lock id. Please see the comments from Mark regarding the same on an earlier version. I think I understand and agree with Mark generally, but in this case, the hwlock id is not an implementation detail. Unlike GPIOs/DMAs, this id number is global and system-wide (Linux is just one component in the system, and must use the same predefined id numbers all other cores use, otherwise it will be impossible to use those hwlocks for multi-core synchronization). Yes, I agree this is an issue if we have to have the base_ids fixed per controller. Do you see any other way this could work if the base_ids were not predefined? Linux and some other core running a different OS must agree on the id numbers of the hardware locks we have in the system. So far, we have not come across multiple controllers. I see your point, and I think this also depends on the semantics of how you exchange the lock id number. The agreement at the moment is on base_ids across multiple SoC components. If the semantics involve exchanging the controller instance, for example, then we might get away with it. But that probably involves adding additional helpers to retrieve controller instance in addition to lock number, or some other similar functions. I can add back the hwlock-base-id binding to the controller node. Mark, Kumar, Do you have any issues adding back this element for registration purposes? Before DT came along, early board code could have reserved specific hwspinlocks if needed. Now with DT, we should add the list of reserved locks to the controller node, in order to prevent them from being dynamically allocated by others. But that strictly relied on the order of requests without any core changes in the hwspinlock core, right. I don't think so, you could request a specific lock by id number. Sorry, I should have rephrased it better - by order, I meant the inherent order between board early code and other drivers. With DT, we cannot guarantee that right, as specific locks are requested from drivers. With DT, the early board code is much simplified. Looking at the same scenario from DT case, it seems kinda redundant to specify a set of reserved locks both in the controller node, as well as the respective client drivers, as there is almost no platform data with DT. The only use case for DT client nodes would be for requesting specific locks. I agree with the problem you described, and I think it will require a different set of changes to the core. Exactly. The platform-specific hwspinlock driver will have to inform the core, upon registration, which of the locks are already reserved. In turn, the core will never provide them to clients that dynamically allocate an hwlock: they will be provided only to clients that ask for them specifically (using phandle+specifier). Understood. And we may have to assign the client association with a lock as well. These are core changes that were actually not needed in the non-DT case due to the inherent order as stated above. So, are you suggesting that we add one more property to the controller node to mark which are reserved, or rely on constructing this through DT tree parsing? 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: [PATCH 1/5] iommu/omap: Use the cache cleaning API
On 03/17/2014 06:12 PM, Laurent Pinchart wrote: Hi Arnd, On Friday 14 March 2014 17:57:48 Arnd Bergmann wrote: On Friday 14 March 2014, Santosh Shilimkar wrote: I remember NAKing this approach in past and my stand remains same. The cache APIs which you are trying to use here are not suppose to be used outside. I think the right way to fix this is to make use of streaming APIs. If needed, IOMMU can have its own dma_ops for special case handling if any. Russell, Arnd might have more ideas. I have a bad feeling about using the dma-mapping API within the IOMMU code, because that driver is also used to implement the dma-mapping API for devices attached to the IOMMU. It's possible that it just works. Right, but I hope the memory port used by the IOMMU to fetch page table entries will not go through itself the same IOMMU :-) Is the IOMMU actually designed to have page tables in noncoherent memory? I would have expected that the iopt accesses must all be done on dma_alloc_coherent() provided memory to guarantee proper accesses. I'm not knowledgeable enough about the OMAP IOMMU, but at least the Renesas IOMMU doesn't need coherent memory as long as the driver makes sure that changes to the page tables are made visible to the device. That is the case with OMAP IOMMU as well, we have all along been using non-coherent memory. Switching to coherent memory will probably simplify things in the IOMMU driver (and eliminate this discussion on OMAP :)) 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: OMAP4 SDP regression...
* Russell King - ARM Linux li...@arm.linux.org.uk [140317 16:35]: There's been a couple of regressions on OMAP4430 SDP I've only recently noticed: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=1597 Configuring network interfaces... udhcpc (v1.9.1) started Sending discover... Sending discover... Sending discover... No lease, failing done. No link lights come up either. The hardware is fine because uboot manages to successfully tftp the kernel. It looks like it was working in -rc4+armsoc and -rc5+armsoc, but not -rc6+armsoc. From what I can see, nothing has changed in drivers/net/ethernet/micrel/ since rc5. I've been through the delta from 3.14-rc5, and I don't see anything obvious. Any ideas? Known problem? Seems like plain v3.14-rc6 fails for me while -rc5 works. Bisecting points to: 66fda75f regulator: core: Replace direct ops-disable usage Also verified that v3.14-rc6 with 66fda75f reverted also works. Markus Mark, any ideas? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: Add machine entry for dra72x devices
On Saturday 15 March 2014 07:51 AM, Suman Anna wrote:
Hi Rajendra,
On 03/14/2014 04:20 AM, Nayak, Rajendra wrote:
The only difference from the dra75x devices is the missing .smp entry.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 8e3daa1..d803d99 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -253,4 +253,22 @@ DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened
Device Tree))
.dt_compat= dra7xx_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
+
+static const char *dra72_boards_compat[] __initdata = {
How about using dra72x_ instead of dra72_ and keeping it consistent
at the other places as well?
Sure, I can do that. Thanks.
regards
Suman
+ti,dra72x,
+ti,dra7,
+NULL,
+};
+
+DT_MACHINE_START(DRA72_DT, Generic DRA72 (Flattened Device Tree))
+.reserve= omap_reserve,
+.map_io= omap5_map_io,
+.init_early= dra7xx_init_early,
+.init_late= dra7xx_init_late,
+.init_irq= omap_gic_of_init,
+.init_machine= omap_generic_init,
+.init_time= omap5_realtime_timer_init,
+.dt_compat= dra72_boards_compat,
+.restart= omap44xx_restart,
+MACHINE_END
#endif
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP5: DSS hwmod data
On 17/03/14 16:22, Dmitry Lifshitz wrote: Hi Tomi, Unfortunately, I have a lack of experience with DT DSS stuff. How should I define the endpoints and the connector in my case? Please, could you provide some reference. See Documentation/devicetree/bindings/media/video-interfaces.txt for a description of the ports and endpoints. If your board is similar to uevm except you don't have the tpd12s015, then you just need to remove the tpd12s015 from the .dts file, and connect the OMAP's HDMI output directly to the connector. Regarding omapfb, is it sufficient to turn it on in the Kernel config? Yes. Tomi signature.asc Description: OpenPGP digital signature
