Re: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock
On 05/28, Tero Kristo wrote: On 05/28/2015 07:22 AM, Michael Turquette wrote: Just chiming in on the critical clock discussion. I'm not planning to merge something that lets Devicetree nodes call clk_enable on a clock. That's what drivers are for. The assigned-rate and assigned-parent stuff that Tero mentioned is more like configuration data for a downstream clock consumer. Clock gating/ungating does not fall under this type of configuration data in my opinion. I think that Tomi's patch to call clk_prepare_enable from dra7xx_dt_clk_init is a reasonable solution to the problem. Yea, after this discussion I am fine with this approach also, seeing it apparently doesn't cause any ill side-effects. Well hopefully when the clk is prepared and enabled it isn't orphaned. Or we're going to be in the same problem as we're currently in with Sunxi and trying to make EPROBE_DEFER come out of clk_get(). -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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: [PATCHv3 02/27] clk: ti: move generic OMAP DPLL implementation under drivers/clk
On 05/25, Tero Kristo wrote:
@@ -281,7 +282,7 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
* be rounded, or the rounded rate upon success.
*/
long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
- unsigned long *parent_rate)
+unsigned long *parent_rate)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
int m, n, r, scaled_max_m;
@@ -310,7 +311,6 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
dd-last_rounded_rate = 0;
for (n = dd-min_divider; n = dd-max_divider; n++) {
-
/* Is the (input clk, divider) pair valid for the DPLL? */
r = _dpll_test_fint(clk, n);
if (r == DPLL_FINT_UNDERFLOW)
@@ -367,4 +367,3 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
return dd-last_rounded_rate;
}
-
It's a lot easier to see the cleanup that happened while copying
code over. Thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: [PATCHv3 01/27] ARM: OMAP2+: clock: export driver API to setup/get clock features
On 05/25, Tero Kristo wrote:
+
+/**
+ * ti_clk_get_features - get clock driver features flags
+ *
+ * Get TI clock driver features description. Returns a pointer
+ * to the current feature setup.
+ */
+struct ti_clk_features *ti_clk_get_features(void)
const?
+{
+ return ti_clk_features;
+}
#endif
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Matthijs van Duin matthijsvand...@gmail.com [150528 13:28]: On 28 May 2015 at 18:01, Tony Lindgren t...@atomide.com wrote: For failed device access you get an interrupt Well for failed reads you get a bus error, and catching those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Hmm I believe the interrupt happens immediately trying to access an invalid device. But maybe I'm thinking about just errors if a device is not powered or clocked. So obviously some experiments need to be done :) The advantage here would be that the l3 driver actually already knows quite a bit about the devices on the bus. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Oh OK yeah then that would not work for Pali's case. I guess it just needs to be tested. 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 28 May 2015 at 18:01, Tony Lindgren t...@atomide.com wrote: For failed device access you get an interrupt Well for failed reads you get a bus error, and catching those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Matthijs -- 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Friday 29 May 2015 00:24:13 Tony Lindgren wrote: * Matthijs van Duin matthijsvand...@gmail.com [150528 13:28]: On 28 May 2015 at 18:01, Tony Lindgren t...@atomide.com wrote: For failed device access you get an interrupt Well for failed reads you get a bus error, and catching those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Hmm I believe the interrupt happens immediately trying to access an invalid device. But maybe I'm thinking about just errors if a device is not powered or clocked. So obviously some experiments need to be done :) The advantage here would be that the l3 driver actually already knows quite a bit about the devices on the bus. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Oh OK yeah then that would not work for Pali's case. I guess it just needs to be tested. Regards, Tony Ok, thanks for info. Do you have some quick small patches for testing? Or some pointers what is needed to modify and how? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [RFC] Fix omap3 booting with thumb2 compiled kernel
* Arnd Bergmann a...@arndb.de [150528 11:57]: On Thursday 28 May 2015 09:36:05 Tony Lindgren wrote: * Dave Martin dave.mar...@arm.com [150528 09:19]: On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote: --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -203,23 +203,8 @@ save_context_wfi: */ ldr r1, kernel_flush blx r1 - /* -* The kernel doesn't interwork: v7_flush_dcache_all in particluar will -* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. -* This sequence switches back to ARM. Note that .align may insert a -* nop: bx pc needs to be word-aligned in order to work. -*/ - THUMB(.thumb ) - THUMB(.align ) - THUMB(bx pc ) - THUMB(nop ) - .arm - ^ This looks unrelated to the issue? This code is simply unnecessary after Russell introduced the ret macro in commit 6ebbf2ce43. That made v7_flush_dcache_all do a proper interworking return. It should probably be in a separate commit, or at least mentioned explicitly in the commit log. Thanks, I've updated the description with the commit info above. I'll keep the removal of the duplicate code in this patch, as it's all related to the mode switching and we don't want to do it twice. I would have thought that the change is actually necessary after 6ebbf2ce43, because it now returns in ARM mode, which will cause the bx pc; nop thumb instruction sequence be misinterpreted as an ARM instruction. Could be it's necessary.. But alone that change is not enough. 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] Fix omap3 booting with thumb2 compiled kernel
On Thursday 28 May 2015 09:36:05 Tony Lindgren wrote: * Dave Martin dave.mar...@arm.com [150528 09:19]: On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote: --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -203,23 +203,8 @@ save_context_wfi: */ ldr r1, kernel_flush blx r1 - /* -* The kernel doesn't interwork: v7_flush_dcache_all in particluar will -* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. -* This sequence switches back to ARM. Note that .align may insert a -* nop: bx pc needs to be word-aligned in order to work. -*/ - THUMB(.thumb ) - THUMB(.align ) - THUMB(bx pc ) - THUMB(nop ) - .arm - ^ This looks unrelated to the issue? This code is simply unnecessary after Russell introduced the ret macro in commit 6ebbf2ce43. That made v7_flush_dcache_all do a proper interworking return. It should probably be in a separate commit, or at least mentioned explicitly in the commit log. Thanks, I've updated the description with the commit info above. I'll keep the removal of the duplicate code in this patch, as it's all related to the mode switching and we don't want to do it twice. I would have thought that the change is actually necessary after 6ebbf2ce43, because it now returns in ARM mode, which will cause the bx pc; nop thumb instruction sequence be misinterpreted as an ARM instruction. 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: [RFC] Fix omap3 booting with thumb2 compiled kernel
On Thu, May 28, 2015 at 09:36:05AM -0700, Tony Lindgren wrote: * Dave Martin dave.mar...@arm.com [150528 09:19]: On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote: --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -203,23 +203,8 @@ save_context_wfi: */ ldr r1, kernel_flush blx r1 - /* - * The kernel doesn't interwork: v7_flush_dcache_all in particluar will - * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. - * This sequence switches back to ARM. Note that .align may insert a - * nop: bx pc needs to be word-aligned in order to work. - */ - THUMB( .thumb ) - THUMB( .align ) - THUMB( bx pc ) - THUMB( nop ) - .arm - ^ This looks unrelated to the issue? This code is simply unnecessary after Russell introduced the ret macro in commit 6ebbf2ce43. That made v7_flush_dcache_all do a proper interworking return. It should probably be in a separate commit, or at least mentioned explicitly in the commit log. Thanks, I've updated the description with the commit info above. I'll keep the removal of the duplicate code in this patch, as it's all related to the mode switching and we don't want to do it twice. b omap3_do_wfi - -/* - * Local variables - */ ^ Likewise this is just tidyup, not bug fixing. Will keep that too, the local variables comments are now just too confusing while reading the code after adding the ENDPROC. And that too is just removal. I have no objection to tidyups ;) So long as the commit message is clear about which parts are bugfix and which parts are tidyup, I'm fine with that. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 02:58, Matthijs van Duin matthijsvand...@gmail.com wrote: It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting in a (synchronous) bus error which takes precedence over the out-of-band error irq (if any is signalled). OK, all this was actually assuming linux uses device-type mappings for device mappings, which was also the impression I got from build_mem_type_table() in arch/arm/mm/mmu.c (although it's a bit of a maze). A quick test however seems to imply otherwise: ~# ./bogus-dev-write Bus error So... linux actually uses strongly-ordered mappings? I really didn't expect that, given the performance implications (especially on a strictly in-order cpu like the Cortex-A8 which will really just sit there picking its nose until the write completes) and I think I recall having seen an OCP barrier being used somewhere in driver code... Well, in that case everything I said is technically still true, except the posting point is the peripheral itself. That also means the interconnect error reporting mechanism is not really useful for probing since you'll get a bus error before any error irq is delivered. So I'd say you're back at having to trap that bus error using the exception handling mechanism, which I still suspect shouldn't be hard to do. Or perhaps you could probe the device using a DMA access and combine that with the interconnect error reporting irq... ;-) -- 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Pali Rohár pali.ro...@gmail.com [150528 15:29]: On Friday 29 May 2015 00:24:13 Tony Lindgren wrote: * Matthijs van Duin matthijsvand...@gmail.com [150528 13:28]: On 28 May 2015 at 18:01, Tony Lindgren t...@atomide.com wrote: For failed device access you get an interrupt Well for failed reads you get a bus error, and catching those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Hmm I believe the interrupt happens immediately trying to access an invalid device. But maybe I'm thinking about just errors if a device is not powered or clocked. So obviously some experiments need to be done :) The advantage here would be that the l3 driver actually already knows quite a bit about the devices on the bus. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Oh OK yeah then that would not work for Pali's case. I guess it just needs to be tested. Regards, Tony Ok, thanks for info. Do you have some quick small patches for testing? Or some pointers what is needed to modify and how? Well I guess the initial test would be to make sure you have CONFIG_OMAP_INTERCONNECT=y, comment out status = disabled in omap3-n900.dts for aes, patch in the aes hwmod data, check that you have CONFIG_CRYPTO_DEV_OMAP_AES=y, boot the kernel. Do you get just the l3_smx interrupt instead of the Unhandled fault? If so then we can use the interrupt handle to make the probe fail. Not sure yet what would be the best way to do that though :) 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 00:24, Tony Lindgren t...@atomide.com wrote: Hmm I believe the interrupt happens immediately trying to access an invalid device. But maybe I'm thinking about just errors if a device is not powered or clocked. It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting in a (synchronous) bus error which takes precedence over the out-of-band error irq (if any is signalled). Once the write is posted however, the cpu will receive an ack on the write and continue execution, and there's no reason to assume that an error irq will happen *immediately* after the write. Of course it typically will happen soon afterwards, possibly even before the next instruction is executed, depending a bit on how soon after the posting-point the error occurs versus how long it takes for the write-ack to reach the cpu. On the other hand, it's also possible the write, after becoming posted, gets stuck for a while due to a burst of higher-priority traffic. (I also recall reading about some situation where a request needs to wait for something to be dynamically powered up before an error response could be generated, but I think that was on the OMAP 4.) So that's the icky part: it will very likely happen almost immediately. There's however no *guarantee* that it will, and in fact it's quite tricky to absolutely make sure a write is no longer in transit. The usual solution is an OCP barrier: a read that is known to follow the same path as the write. Normally that means a read from the same peripheral, but that would defeat the purpose in this case. Fortunately, the L4 interconnects (unlike the L3) detect firewall violations in the initiator agent rather than the target agents, hence a read from any peripheral on the same L4 interconnect suffices. -- 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: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock
On 05/28/2015 07:22 AM, Michael Turquette wrote: Quoting Stephen Boyd (2015-05-20 12:34:23) On 05/20/15 04:50, Tero Kristo wrote: @@ -348,5 +348,10 @@ int __init dra7xx_dt_clk_init(void) if (rc) pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__); +hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk); +rc = clk_prepare_enable(hdcp_ck); +if (rc) +pr_err(%s: failed to set dss_deshdcp_clk\n, __func__); + return rc; } You should rather use the assigned-clock properties in DT to accomplish this, the manual clock tweaks under the drivers/clk/ti/clk-* files should be converted to DT setup also. Now that I sent this, I realize we only have support to set_parent / set_rate through the assigned-clock props, no enable. Any plans to extend this support Mike/Stephen? Enable falls under the critical clocks discussion that is ongoing. I assume that this is some sort of critical clock that can't be turned off? Just chiming in on the critical clock discussion. I'm not planning to merge something that lets Devicetree nodes call clk_enable on a clock. That's what drivers are for. The assigned-rate and assigned-parent stuff that Tero mentioned is more like configuration data for a downstream clock consumer. Clock gating/ungating does not fall under this type of configuration data in my opinion. I think that Tomi's patch to call clk_prepare_enable from dra7xx_dt_clk_init is a reasonable solution to the problem. Yea, after this discussion I am fine with this approach also, seeing it apparently doesn't cause any ill side-effects. -Tero Regards, Mike -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 05/13] mmc: omap_hsmmc: Support for deferred probing when requesting DMA channels
On 26 May 2015 at 15:26, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
I guess it should be dma_request_slave_... huh, that was a long name. :-)
channels. In case of error, return the error code we received including
-EPROBE_DEFER
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
With the minor change above.
Acked-by: Ulf Hansson ulf.hans...@linaro.org
Kind regards
Uffe
---
drivers/mmc/host/omap_hsmmc.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 57bb85930f81..d252478391ee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2088,23 +2088,21 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-rx_chan =
- dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-rx_req, pdev-dev, rx);
+ host-rx_chan = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, rx_req, pdev-dev,
rx);
- if (!host-rx_chan) {
+ if (IS_ERR(host-rx_chan)) {
dev_err(mmc_dev(host-mmc), unable to obtain RX DMA engine
channel %u\n, rx_req);
- ret = -ENXIO;
+ ret = PTR_ERR(host-rx_chan);
goto err_irq;
}
- host-tx_chan =
- dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-tx_req, pdev-dev, tx);
+ host-tx_chan = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, tx_req, pdev-dev,
tx);
- if (!host-tx_chan) {
+ if (IS_ERR(host-tx_chan)) {
dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine
channel %u\n, tx_req);
- ret = -ENXIO;
+ ret = PTR_ERR(host-tx_chan);
goto err_irq;
}
@@ -2166,9 +2164,9 @@ err_slot_name:
if (host-use_reg)
omap_hsmmc_reg_put(host);
err_irq:
- if (host-tx_chan)
+ if (!IS_ERR_OR_NULL(host-tx_chan))
dma_release_channel(host-tx_chan);
- if (host-rx_chan)
+ if (!IS_ERR_OR_NULL(host-rx_chan))
dma_release_channel(host-rx_chan);
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
--
2.3.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 07/13] mmc: davinci_mmc: Support for deferred probing when requesting DMA channels
On 26 May 2015 at 15:26, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. Only fall back to pio mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Ulf Hansson ulf.hans...@linaro.org
Kind regards
Uffe
---
drivers/mmc/host/davinci_mmc.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index b2b3f8bbfd8c..df81e4e2f662 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -530,20 +530,20 @@ static int __init davinci_acquire_dma_channels(struct
mmc_davinci_host *host)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-dma_tx =
- dma_request_slave_channel_compat(mask, edma_filter_fn,
- host-txdma, mmc_dev(host-mmc), tx);
- if (!host-dma_tx) {
+ host-dma_tx = dma_request_slave_channel_compat_reason(mask,
+ edma_filter_fn, host-txdma,
+ mmc_dev(host-mmc), tx);
+ if (IS_ERR(host-dma_tx)) {
dev_err(mmc_dev(host-mmc), Can't get dma_tx channel\n);
- return -ENODEV;
+ return PTR_ERR(host-dma_tx);
}
- host-dma_rx =
- dma_request_slave_channel_compat(mask, edma_filter_fn,
- host-rxdma, mmc_dev(host-mmc), rx);
- if (!host-dma_rx) {
+ host-dma_rx = dma_request_slave_channel_compat_reason(mask,
+ edma_filter_fn, host-rxdma,
+ mmc_dev(host-mmc), rx);
+ if (IS_ERR(host-dma_rx)) {
dev_err(mmc_dev(host-mmc), Can't get dma_rx channel\n);
- r = -ENODEV;
+ r = PTR_ERR(host-dma_rx);
goto free_master_write;
}
@@ -1307,8 +1307,12 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
host-mmc_irq = irq;
host-sdio_irq = platform_get_irq(pdev, 1);
- if (host-use_dma davinci_acquire_dma_channels(host) != 0)
+ if (host-use_dma) {
+ ret = davinci_acquire_dma_channels(host);
+ if (ret == -EPROBE_DEFER)
+ goto out;
host-use_dma = 0;
+ }
/* REVISIT: someday, support IRQ-driven card detection. */
mmc-caps |= MMC_CAP_NEEDS_POLL;
--
2.3.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 04/13] mmc: omap_hsmmc: No need to check DMA channel validity at module remove
On 26 May 2015 at 15:25, Peter Ujfalusi peter.ujfal...@ti.com wrote: The driver will not probe without valid DMA channels so no need to check if they are valid when the module is removed. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Ulf Hansson ulf.hans...@linaro.org Acked-by: Ulf Hansson ulf.hans...@linaro.org Kind regards Uffe --- drivers/mmc/host/omap_hsmmc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2cd828f42151..57bb85930f81 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2190,10 +2190,8 @@ static int omap_hsmmc_remove(struct platform_device *pdev) if (host-use_reg) omap_hsmmc_reg_put(host); - if (host-tx_chan) - dma_release_channel(host-tx_chan); - if (host-rx_chan) - dma_release_channel(host-rx_chan); + dma_release_channel(host-tx_chan); + dma_release_channel(host-rx_chan); pm_runtime_put_sync(host-dev); pm_runtime_disable(host-dev); -- 2.3.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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Wednesday 11 February 2015 14:40:33 Nishanth Menon wrote: On Wed, Feb 11, 2015 at 2:28 PM, Pali Rohár pali.ro...@gmail.com wrote: On Wednesday 11 February 2015 16:22:51 Matthijs van Duin wrote: On 11 February 2015 at 13:39, Pali Rohár pali.ro...@gmail.com wrote: Anyhow, since checking the firewalls/APs to see if you have permission will probably only get you yet another fault if things are walled off, the robust way of dealing with this sort of situation is by probing the device with a read while trapping bus faults. This also handles modules that are unreachable for other reasons, e.g. being disabled by eFuse. It is possible to patch kernel code to mask or ignore that fault? Can you help me with something like that? As I mentioned, I'm still learning my way around the kernel, so I don't feel very comfortable suggesting a concrete patch just yet. I've been browsing arch/arm/mm/ however and my impression is that all that would be required is editing fault.c by making a copy of do_bad but containing return user_mode(regs) || !fixup_exception(regs); and hook it onto the appropriate fault codes. However, this really needs the opinion of someone more familiar with this code. I do have an observation to make on the issue of fault decoding: the list in fsr-2level.c may be standard ARMv3 and ARMv4 aborts but they are quite wrong for ARMv7 which has: [ 0] - [ 1] alignment fault [ 2] debug event [ 3] section access flag fault [ 4] instruction cache maintainance fault (reported via data abort) [ 5] section translation fault [ 6] page access flag fault [ 7] page translation fault [ 8] bus error on access [ 9] section domain fault [10] - [11] page domain fault [12] bus error on section table walk [13] section permission fault [14] bus error on page table walk [15] page permission fault [16] (TLB conflict abort) [17] - [18] - [19] - [20] (lockdown abort) [21] - [22] async bus error (reported via data abort) [23] - [24] async parity/ECC error (reported via data abort) [25] parity/ECC error on access [26] (coprocessor abort) [27] - [28] parity/ECC error on section table walk [29] - [30] parity/ECC error on page table walk [31] - Some entries are patched up near the bottom of fault.c but many bogus messages remain, for example the on linefetch vs on non-linefetch is misleading since no such thing can be inferred from the fault status on v7. Also, the i-cache maintenance fault handling looks wrong to me: it should fetch the actual fault status from IFSR (even though the address still comes from DFSR) and dispatch based on that. Async external aborts (async bus error and async parity/ECC error) give you basically no info. DFAR will contain garbage hence displaying it will confuse rather than enlighten, a traceback is pointless since the instruction that caused the access is long retired, likewise user_mode() doesn't matter since a transition to kernel space may have happened after the access that cause the abort. Basically they should be treated more as an IRQ than as a fault (note they can also be masked just like irqs). In case of a bus error, it may be appropriate to just warn about it, or perhaps send a signal to the current process, although in the latter case it should have some means to distinguish it from a synchronous bus error. At least on the cortex-a8, a parity/ECC error (whether async or not) is to be regarded as absolutely fatal. Quoth the TRM: No recovery is possible. The abort handler must disable the caches, communicate the fail directly with the external system, request a reboot. Bit 10 no longer indicates an asynchronous (let alone imprecise) fault. Apart from the debug events and async aborts (and possibly some implementation-defined aborts), all aborts listed are synchronous, and DFAR/IFAR is valid. There's no technical obstruction to make these trappable via the kernel exception handling mechanism. (Though at least in case of parity/ECC errors one shouldn't.) Tony, Nishanth, or somebody else... can you help with memory management? Or do you know some expert for arch/arm/mm/ code? Folks in linux-arm-kernel are probably the right people, I suppose. Looping them in. So pinging linux-arm-kernel again. Any idea how to handle that fault? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fbdev: omap2: improve usage of gpiod API
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Also make use of gpiod_get*_optional where applicable.
Apart from simplification of the affected drivers this is another step
towards making the flags argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 12 +++-
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 13 +++--
.../fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c | 7 +++
.../fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c | 9 ++---
4 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
b/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
index 84a6b3367124..a14d993f719d 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
@@ -201,15 +201,9 @@ static int opa362_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
- gpio = devm_gpiod_get(pdev-dev, enable);
- if (IS_ERR(gpio)) {
- if (PTR_ERR(gpio) != -ENOENT)
- return PTR_ERR(gpio);
-
- gpio = NULL;
- } else {
- gpiod_direction_output(gpio, 0);
- }
+ gpio = devm_gpiod_get_optional(pdev-dev, enable, GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
ddata-enable_gpio = gpio;
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index eb8fd8140ad0..f7be3489f744 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -209,16 +209,9 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
struct videomode vm;
struct gpio_desc *gpio;
- gpio = devm_gpiod_get(pdev-dev, enable);
-
- if (IS_ERR(gpio)) {
- if (PTR_ERR(gpio) != -ENOENT)
- return PTR_ERR(gpio);
- else
- gpio = NULL;
- } else {
- gpiod_direction_output(gpio, 0);
- }
+ gpio = devm_gpiod_get_optional(pdev-dev, enable, GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
ddata-enable_gpio = gpio;
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
index 9974a37a11af..6a1b6a89a928 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
@@ -285,15 +285,14 @@ static int lb035q02_probe_of(struct spi_device *spi)
struct omap_dss_device *in;
struct gpio_desc *gpio;
- gpio = devm_gpiod_get(spi-dev, enable);
+ gpio = devm_gpiod_get(spi-dev, enable, GPIOD_OUT_LOW);
if (IS_ERR(gpio)) {
dev_err(spi-dev, failed to parse enable gpio\n);
return PTR_ERR(gpio);
- } else {
- gpiod_direction_output(gpio, 0);
- ddata-enable_gpio = gpio;
}
+ ddata-enable_gpio = gpio;
+
ddata-backlight_gpio = -ENOENT;
in = omapdss_of_find_source_for_first_ep(node);
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index eae263702964..abfd1f6e3327 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -268,17 +268,12 @@ static int sharp_ls_get_gpio_of(struct device *dev, int
index, int val,
const char *desc, struct gpio_desc **gpiod)
{
struct gpio_desc *gd;
- int r;
*gpiod = NULL;
- gd = devm_gpiod_get_index(dev, desc, index);
+ gd = devm_gpiod_get_index(dev, desc, index, GPIOD_OUT_LOW);
if (IS_ERR(gd))
- return PTR_ERR(gd) == -ENOENT ? 0 : PTR_ERR(gd);
-
- r = gpiod_direction_output(gd, val);
- if (r)
- return r;
+ return PTR_ERR(gd);
*gpiod = gd;
return 0;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Fix omap3 booting with thumb2 compiled kernel
On Thu, May 28, 2015 at 1:55 AM, Tony Lindgren t...@atomide.com wrote: 8 -- From: Tony Lindgren t...@atomide.com Date: Wed, 27 May 2015 15:33:57 -0700 Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel We get a NULL pointer dereference on omap3 for thumb2 compiled kernels: Internal error: Oops: 8005 [#1] SMP THUMB2 ... [c046497b] (_raw_spin_unlock_irqrestore) from [c0024375] (omap3_enter_idle_bm+0xc5/0x178) [c0024375] (omap3_enter_idle_bm) from [c0374e63] (cpuidle_enter_state+0x77/0x27c) [c0374e63] (cpuidle_enter_state) from [c00627f1] (cpu_startup_entry+0x155/0x23c) [c00627f1] (cpu_startup_entry) from [c06b9a47] (start_kernel+0x32f/0x338) [c06b9a47] (start_kernel) from [8000807f] (0x8000807f) The power management related assembly on moaps needs to interact with moaps - omaps Gražvydas -- 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: drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
Hi Nishanth,
Do you mind rebasing that one so I can apply it?
On 21/08/2014 at 11:12:01 -0500, Nishanth Menon wrote :
With the recent pinctrl-single changes, SoCs such as Texas
Instrument's OMAP processors can treat wake-up events from deeper idle
states as interrupts.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/rtc/rtc-ds1307.c | 57
++
1 file changed, 57 insertions(+)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index f03d5ba..5feedfc 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -15,6 +15,8 @@
#include linux/init.h
#include linux/slab.h
#include linux/i2c.h
+#include linux/of_device.h
+#include linux/of_irq.h
#include linux/string.h
#include linux/rtc.h
#include linux/bcd.h
@@ -115,6 +117,7 @@ struct ds1307 {
struct i2c_client *client;
struct rtc_device *rtc;
struct work_struct work;
+ int wakeirq;
s32 (*read_block_data)(const struct i2c_client *client, u8 command,
u8 length, u8 *values);
s32 (*write_block_data)(const struct i2c_client *client, u8 command,
@@ -835,6 +838,34 @@ ds1307_nvram_write(struct file *filp, struct kobject
*kobj,
/*--*/
+static int ds1307_i2c_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+ struct ds1307 *ds1307 = i2c_get_clientdata(client);
+ struct device *dev = client-dev;
+
+ if (!ds1307-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(ds1307-wakeirq);
+
+ return 0;
+}
+
+static int ds1307_i2c_resume(struct i2c_client *client)
+{
+ struct ds1307 *ds1307 = i2c_get_clientdata(client);
+ struct device *dev = client-dev;
+
+ if (!ds1307-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ disable_irq_nosync(ds1307-wakeirq);
+
+ return 0;
+}
+
static int ds1307_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -1116,6 +1147,8 @@ read_rtc:
}
if (want_irq) {
+ struct device_node *node = client-dev.of_node;
+
err = request_irq(client-irq, ds1307_irq, IRQF_SHARED,
ds1307-rtc-name, client);
if (err) {
@@ -1125,6 +1158,28 @@ read_rtc:
set_bit(HAS_ALARM, ds1307-flags);
dev_dbg(client-dev, got IRQ %d\n, client-irq);
+ if (node)
+ ds1307-wakeirq = irq_of_parse_and_map(node, 1);
+
+ if (ds1307-wakeirq = 0)
+ ds1307-wakeirq = 0;
+ else
+ err = devm_request_irq(client-dev,
+ds1307-wakeirq,
+ds1307_irq,
+IRQF_ONESHOT,
+ds1307-rtc-name,
+client);
+ if (err) {
+ dev_err(client-dev, unable to get wakeIRQ
%d\n,
+ err);
+ free_irq(client-irq, client);
+ goto exit;
+ }
+
+ /* We enable the interrupt only during suspend path */
+ if (ds1307-wakeirq)
+ disable_irq_nosync(ds1307-wakeirq);
}
}
@@ -1189,6 +1244,8 @@ static struct i2c_driver ds1307_driver = {
},
.probe = ds1307_probe,
.remove = ds1307_remove,
+ .suspend= ds1307_i2c_suspend,
+ .resume = ds1307_i2c_resume,
.id_table = ds1307_id,
};
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
Hi Alexandre, On 05/28/2015 08:06 AM, Alexandre Belloni wrote: Do you mind rebasing that one so I can apply it? Thanks for responding. I see Tony has done a changes in [1] - So, I will respin my series and repost. [1] http://marc.info/?l=linux-omapm=143156023023154w=2 -- 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: [RFC] Fix omap3 booting with thumb2 compiled kernel
* Grazvydas Ignotas nota...@gmail.com [150528 04:45]:
On Thu, May 28, 2015 at 1:55 AM, Tony Lindgren t...@atomide.com wrote:
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 27 May 2015 15:33:57 -0700
Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on moaps needs to interact with
moaps - omaps
Thanks, fixed now. I also added a link for why ENDPROC is needed to the
description. I'll apply the patch below into fixes today.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 27 May 2015 15:33:57 -0700
Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.
Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's add the
missing ENDPROC in two places to sleep34xx.S, and also remove the
earlier mystery code that was probably also caused by missing ENDPROC
for earlier kernels.
The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
*/
ldr r1, kernel_flush
blx r1
- /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM. Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb )
- THUMB(.align )
- THUMB(bx pc )
- THUMB(nop )
- .arm
-
b omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
* ===
*/
ldmfd sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
sdrc_power:
.word SDRC_POWER_V
cm_idlest1_core:
--
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] mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq
* Tony Lindgren t...@atomide.com [150527 15:46]: * Rafael J. Wysocki rafael.j.wyso...@intel.com [150527 15:44]: On 5/25/2015 10:38 AM, Ulf Hansson wrote: On 14 May 2015 at 01:36, Tony Lindgren t...@atomide.com wrote: We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts. Signed-off-by: Tony Lindgren t...@atomide.com Rafael, if you are fine with it, please take this one through your linux-pm tree. Acked-by: Ulf Hansson ulf.hans...@linaro.org I thought that Tony would resubmit this one. Tony? OK I can queue it with Ulf's ack via arm-soc no problem. I've applied this one now into omap-for-v4.2/wakeirq branch that's based on Rafael's pm-wakeirq branch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] serial: omap: Switch wake-up interrupt to generic wakeirq
Hi Greg, * Tony Lindgren t...@atomide.com [150513 16:38]: We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts. How do you prefer to handle the two omap specific serial driver changes in this series? There's a dependency to Rafael's pm-wakeirq branch that contains: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling) 56f487c78015 (PM / Runtime: Update last_busy in rpm_resume) f6a2fbb903d5 (PM / runtime: add note about re-calling in during device probe()) The 8250_omap.c driver change also needs to be merged with: 9e91597f2423 (serial: 8250_omap: provide complete custom startup shutdown callbacks) Not sure if 9e91597f2423 is immutable, but if so then I could: a) Send you a pull request for the two serial driver patches based on Rafael's pm-wakeirq branch merged with 9e91597f2423 to avoid the merge conflict. b) Apply both serial driver patches into omap-for-v4.2/wakeirq based on Rafael's pm-wakeirq branch merged with 9e91597f2423. Or do you have some better ideas? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Fix omap3 booting with thumb2 compiled kernel
On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote:
* Grazvydas Ignotas nota...@gmail.com [150528 04:45]:
On Thu, May 28, 2015 at 1:55 AM, Tony Lindgren t...@atomide.com wrote:
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 27 May 2015 15:33:57 -0700
Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on moaps needs to interact with
moaps - omaps
Thanks, fixed now. I also added a link for why ENDPROC is needed to the
description. I'll apply the patch below into fixes today.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 27 May 2015 15:33:57 -0700
Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.
Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's add the
missing ENDPROC in two places to sleep34xx.S, and also remove the
earlier mystery code that was probably also caused by missing ENDPROC
for earlier kernels.
The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
*/
ldr r1, kernel_flush
blx r1
- /*
- * The kernel doesn't interwork: v7_flush_dcache_all in particluar will
- * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
- * This sequence switches back to ARM. Note that .align may insert a
- * nop: bx pc needs to be word-aligned in order to work.
- */
- THUMB( .thumb )
- THUMB( .align )
- THUMB( bx pc )
- THUMB( nop )
- .arm
-
^ This looks unrelated to the issue? This code is simply unnecessary
after Russell introduced the ret macro in commit 6ebbf2ce43. That
made v7_flush_dcache_all do a proper interworking return.
It should probably be in a separate commit, or at least mentioned
explicitly in the commit log.
b omap3_do_wfi
-
-/*
- * Local variables
- */
^ Likewise this is just tidyup, not bug fixing.
+ENDPROC(omap34xx_cpu_suspend)
omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
* ===
*/
ldmfd sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
The ENDPROC()s look appropriate here.
[...]
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Fix omap3 booting with thumb2 compiled kernel
* Dave Martin dave.mar...@arm.com [150528 09:19]:
On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote:
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
*/
ldr r1, kernel_flush
blx r1
- /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM. Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb )
- THUMB(.align )
- THUMB(bx pc )
- THUMB(nop )
- .arm
-
^ This looks unrelated to the issue? This code is simply unnecessary
after Russell introduced the ret macro in commit 6ebbf2ce43. That
made v7_flush_dcache_all do a proper interworking return.
It should probably be in a separate commit, or at least mentioned
explicitly in the commit log.
Thanks, I've updated the description with the commit info above.
I'll keep the removal of the duplicate code in this patch, as it's
all related to the mode switching and we don't want to do it twice.
b omap3_do_wfi
-
-/*
- * Local variables
- */
^ Likewise this is just tidyup, not bug fixing.
Will keep that too, the local variables comments are now just too
confusing while reading the code after adding the ENDPROC. And that
too is just removal.
+ENDPROC(omap34xx_cpu_suspend)
omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
* ===
*/
ldmfd sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
The ENDPROC()s look appropriate here.
OK thanks for looking, I was hoping you'd check it as you did the
original thumb2 changes for this file :) Updated patch below.
Regards,
Tony
8
From: Tony Lindgren t...@atomide.com
Date: Thu, 28 May 2015 07:22:08 -0700
Subject: [PATCH] ARM: OMAP3: Fix booting with thumb2 kernel
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)
The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.
Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's fix the
problem by adding ENDPROC in two places to sleep34xx.S.
Let's also remove the now duplicate custom code for mode switching.
This has been unnecessary since commit 6ebbf2ce437b (ARM: convert
all mov.* pc, reg to bx reg for ARMv6+).
And let's also remove the comments about local variables, they are
now just confusing after the ENDPROC.
The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
*/
ldr r1, kernel_flush
blx r1
- /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM. Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb )
- THUMB(.align )
- THUMB(bx pc )
- THUMB(nop )
- .arm
-
b omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
* ===
*/
ldmfd sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
sdrc_power:
.word SDRC_POWER_V
cm_idlest1_core:
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: dts: omap3-devkit8000: Add dm9000 support
* Anthoine Bourgeois anthoine.bourge...@gmail.com [150527 13:02]: Support dm9000 network interface in the device tree of devkit8000 board. Signed-off-by: Anthoine Bourgeois anthoine.bourge...@gmail.com --- Changes since v1: * Fix io-mapping size * Fix comments Applying this one into omap-for-v4.2/dt thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Pali Rohár pali.ro...@gmail.com [150528 00:39]: On Wednesday 11 February 2015 14:40:33 Nishanth Menon wrote: On Wed, Feb 11, 2015 at 2:28 PM, Pali Rohár pali.ro...@gmail.com wrote: On Wednesday 11 February 2015 16:22:51 Matthijs van Duin wrote: On 11 February 2015 at 13:39, Pali Rohár pali.ro...@gmail.com wrote: Anyhow, since checking the firewalls/APs to see if you have permission will probably only get you yet another fault if things are walled off, the robust way of dealing with this sort of situation is by probing the device with a read while trapping bus faults. This also handles modules that are unreachable for other reasons, e.g. being disabled by eFuse. It is possible to patch kernel code to mask or ignore that fault? Can you help me with something like that? As I mentioned, I'm still learning my way around the kernel, so I don't feel very comfortable suggesting a concrete patch just yet. I've been browsing arch/arm/mm/ however and my impression is that all that would be required is editing fault.c by making a copy of do_bad but containing return user_mode(regs) || !fixup_exception(regs); and hook it onto the appropriate fault codes. However, this really needs the opinion of someone more familiar with this code. I do have an observation to make on the issue of fault decoding: the list in fsr-2level.c may be standard ARMv3 and ARMv4 aborts but they are quite wrong for ARMv7 which has: [ 0] - [ 1] alignment fault [ 2] debug event [ 3] section access flag fault [ 4] instruction cache maintainance fault (reported via data abort) [ 5] section translation fault [ 6] page access flag fault [ 7] page translation fault [ 8] bus error on access [ 9] section domain fault [10] - [11] page domain fault [12] bus error on section table walk [13] section permission fault [14] bus error on page table walk [15] page permission fault [16] (TLB conflict abort) [17] - [18] - [19] - [20] (lockdown abort) [21] - [22] async bus error (reported via data abort) [23] - [24] async parity/ECC error (reported via data abort) [25] parity/ECC error on access [26] (coprocessor abort) [27] - [28] parity/ECC error on section table walk [29] - [30] parity/ECC error on page table walk [31] - Some entries are patched up near the bottom of fault.c but many bogus messages remain, for example the on linefetch vs on non-linefetch is misleading since no such thing can be inferred from the fault status on v7. Also, the i-cache maintenance fault handling looks wrong to me: it should fetch the actual fault status from IFSR (even though the address still comes from DFSR) and dispatch based on that. Async external aborts (async bus error and async parity/ECC error) give you basically no info. DFAR will contain garbage hence displaying it will confuse rather than enlighten, a traceback is pointless since the instruction that caused the access is long retired, likewise user_mode() doesn't matter since a transition to kernel space may have happened after the access that cause the abort. Basically they should be treated more as an IRQ than as a fault (note they can also be masked just like irqs). In case of a bus error, it may be appropriate to just warn about it, or perhaps send a signal to the current process, although in the latter case it should have some means to distinguish it from a synchronous bus error. At least on the cortex-a8, a parity/ECC error (whether async or not) is to be regarded as absolutely fatal. Quoth the TRM: No recovery is possible. The abort handler must disable the caches, communicate the fail directly with the external system, request a reboot. Bit 10 no longer indicates an asynchronous (let alone imprecise) fault. Apart from the debug events and async aborts (and possibly some implementation-defined aborts), all aborts listed are synchronous, and DFAR/IFAR is valid. There's no technical obstruction to make these trappable via the kernel exception handling mechanism. (Though at least in case of parity/ECC errors one shouldn't.) Tony, Nishanth, or somebody else... can you help with memory management? Or do you know some expert for arch/arm/mm/ code? Folks in linux-arm-kernel are probably the right people, I suppose. Looping them in. So pinging linux-arm-kernel again. Any idea how to handle that fault? Here's what might work.. You could patch drivers/bus/omap_l3*.c code to probe the devices after the omap_l3 driver interrupts are enabled. For failed device access you get an interrupt so you know to not create the struct device entry for that device. For the working devices you can do the struct device entry and let it probe. So basically we could make the omap_l3* drivers managers for the omap
Re: [PATCH 0/2] Add support for Toby Churchill SL50 board.
* Enric Balletbo i Serra eballe...@gmail.com [150526 04:15]: Hi Tony, These patches add support for a new board based on AM335x processor. If it is ok, take in consideration to include in next DT merge window, please. Applying both into omap-for-v4.2/dt thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
