Re: [PATCH] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
On 01/16/2015 05:06 PM, Thomas Niederprüm wrote: Unfortunately the omap-mcbsp driver only supports synchronous configuration for tx/rx (since almost all McBSP instance can only be used this way). The first stream will configure both tx and rx to have the same properties. Even if you are using McBSP1 which has separate FSX and FSR lines, the driver does not have support for this. From HW point of view this configuration is valid (not something I would expect in any product). I don't think there are or will be other designs than your using this mode... But, if you add some comment around the masking of CLKXM and CLKRM bits that would be great. Do you mean adding it to the commit message or to the code? or both? Since this is something that the driver has not meant to support officially, I prefer both. I just hope that HW designers will not get ideas based on this ;) -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
This issue is defined by a three-way race at disconnect, between
1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep
error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
asynchronously
3) The hardware IP was configured in silicon with
- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
- Synopsys IP version is 3.00a
The IP will auto-suspend itself on device detach with some phy-specific interval
after CSC is cleared by 2)
If 2) and 3) complete before 1), the interrupts it expects will not be generated
by the autosuspended IP, leading to a deadlock. Even later disconnection
procedure would detect that corresponding urb is still in-progress and issue a
ep stop command, auto-suspended IP still won't respond to that command.
this defect would result in this when device detached:
---
[ 99.603544] usb 4-1: USB disconnect, device number 2
[ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
endpoint command.
[ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting host.
[ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
[ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
halting.
[ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
--
As a result, when device detached, we desired to postpone PORTCSC clear behind
disable slot. it's found that all executed ep command related to disconnetion,
are executed before disable slot.
Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
drivers/usb/host/xhci-hub.c |4
drivers/usb/host/xhci.c | 29 +
drivers/usb/host/xhci.h | 24
3 files changed, 57 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..3b8f7fc 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -368,6 +368,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
port_change_bit = warm(BH) reset;
break;
case USB_PORT_FEAT_C_CONNECTION:
+ if ((xhci-quirks XHCI_DISCONNECT_QUIRK)
+ !(readl(addr) PORT_CONNECT))
+ return;
+
status = PORT_CSC;
port_change_bit = connect;
break;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c50d8d2..aa8e02a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3584,6 +3584,33 @@ command_cleanup:
return ret;
}
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+ int max_ports;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ __le32 __iomem **port_array;
+ u32 status;
+
+ /* print debug info */
+ if (hcd-speed == HCD_USB3) {
+ max_ports = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ } else {
+ max_ports = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ }
+
+ if (dev_port_num max_ports) {
+ xhci_err(xhci, %s() port number invalid, __func__);
+ return;
+ }
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status PORT_CONNECT) (status PORT_CSC))
+ writel(status PORT_CSC, port_array[0]);
+}
+
/*
* At this point, the struct usb_device is about to go away, the device has
* disconnected, and all traffic has been stopped and the endpoints have been
@@ -3649,6 +3676,8 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device
*udev)
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(xhci-lock, flags);
+ if (xhci-quirks XHCI_DISCONNECT_QUIRK)
+ xhci_try_to_clear_csc(hcd, udev-portnum);
/*
* Event command completion handler will free any data structures
* associated with the slot. XXX Can free sleep?
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index cc7c5bb..65a65cc 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1560,6 +1560,30 @@ struct xhci_hcd {
#define XHCI_SPURIOUS_WAKEUP (1 18)
/* For controllers with a broken beyond repair streams implementation */
#define XHCI_BROKEN_STREAMS(1 19)
+/*
+ * This issue is defined by a three-way race at disconnect in Synopsis USB3 IP,
+ * between
+ * 1) Class driver interrupt endpoint resheduling attempts if the ISR gave an
ep
+ *error event due to device detach (it would try 3 times)
+ * 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
+ *asynchronously
+ * 3) The hardware IP was configured in silicon with
+ *-
[PATCH v2 0/5] Add support for Fujitsu USB host controller
These patches add support for XHCI compliant Host controller found on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver and last four patch is about quirk implementation of errata in Synopsis DesignWare USB3 IP. Patch 1 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Patch 2 is to add a revison number 3.00a of Synopsis DesignWare USB3 IP core driver. Patch 3 introduces using a quirk based on a errata of Synopsis DesignWare USB3 IP which is versions 3.00a and has hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a result this quirk has to be enabled via platform data or device tree. Patch 4 is to set Synopsis quirk in xhci platform driver based on xhci platform data. Patch 5 introduces a quirk with device disconnection management necessary Synopsys Designware USB3 IP with versions 3.00a and hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub. Successfully tested on Fujitsu mb86s7x board. Changes since v1 (RFC): [https://lkml.org/lkml/2014/12/15/929] - based on Arnd's comment, remove entire unnecessary Fujitsu EHCI/OHCI glue, - based on Felipe's comment, fix mis-using of runtime-pm API and setting dma mask, remove unnecessary comment, and refactor suspend/resume handler in Fujitsu Specific Glue layer in dwc3, - based on Felipe's comment, add more commit log and comments in Synopsis quirk implementation, and separate it into four patches. Sneeker Yeh (5): usb: dwc3: add Fujitsu Specific Glue layer usb: dwc3: add revision number DWC3_REVISION_300A usb: dwc3: Add quirk for Synopsis device disconnection errata xhci: Platform: Set Synopsis device disconnection quirk based on platform data xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core Documentation/devicetree/bindings/usb/dwc3.txt | 17 ++ .../devicetree/bindings/usb/fujitsu-dwc3.txt | 33 drivers/usb/dwc3/Kconfig | 11 ++ drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/core.c|6 + drivers/usb/dwc3/core.h|2 + drivers/usb/dwc3/dwc3-mb86s70.c| 206 drivers/usb/dwc3/host.c|4 + drivers/usb/dwc3/platform_data.h |1 + drivers/usb/host/xhci-hub.c|4 + drivers/usb/host/xhci-plat.c |3 + drivers/usb/host/xhci.c| 29 +++ drivers/usb/host/xhci.h| 24 +++ include/linux/usb/xhci_pdriver.h |4 + 14 files changed, 345 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] xhci: Platform: Set Synopsis device disconnection quirk based on platform data
If an xhci platform has Synopsis device disconnection errata then enable
XHCI_DISCONNECT_QUIRK quirk flag.
Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
drivers/usb/host/xhci-plat.c |3 +++
include/linux/usb/xhci_pdriver.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..40beb95 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node of_property_read_bool(node, usb3-lpm-capable)) ||
(pdata pdata-usb3_lpm_capable))
xhci-quirks |= XHCI_LPM_SUPPORT;
+
+ if (pdata pdata-delay_portcsc_clear)
+ xhci-quirks |= XHCI_DISCONNECT_QUIRK;
/*
* Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
* is called by usb_add_hcd().
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..a37a3a5 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,14 @@
*
* @usb3_lpm_capable: determines if this xhci platform supports USB3
* LPM capability
+ * @delay_portcsc_clear: determines if Synopsis USB3 core has errata in
+ * DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 hardware
+ * configuration.
*
*/
struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+ unsigneddelay_portcsc_clear:1;
};
#endif /* __USB_CORE_XHCI_PDRIVER_H */
--
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
OMAP baseline test results for v3.19-rc4
Here are some basic OMAP test results for Linux v3.19-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc4/20150118192109/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 7/17): 4430es2panda, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.19-rc3 (b1940cd21c0f4abdce101253e860feff547291b0)): text data bsstotal kernel +21600 +216 omap1_defconfig +21600 +216 omap1_defconfig_1510innovator_only +21600 +216 omap1_defconfig_5912osk_only +888 +1440+1032 multi_v7_defconfig -6400 -64 omap2plus_defconfig -20000 -200 omap2plus_defconfig_2430sdp_only 0000 omap2plus_defconfig_am33xx_only 0000 omap2plus_defconfig_am43xx_only -6400 -64 omap2plus_defconfig_cpupm 0000 omap2plus_defconfig_dra7xx_only -1200 -12 omap2plus_defconfig_n800_multi_omap2xxx +180 -80 +172 omap2plus_defconfig_n800_only_a 0000 omap2plus_defconfig_no_pm -6400 -64 omap2plus_defconfig_omap2_4_only 0000 omap2plus_defconfig_omap3_4_only -6400 -64 omap2plus_defconfig_omap5_only +2200 -28 +192 rmk_omap3430_ldp_allnoconfig +16000 +160 rmk_omap3430_ldp_oldconfig +2360 -44
OMAP baseline test results for v3.19-rc5
Here are some basic OMAP test results for Linux v3.19-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc5/20150118212155/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 7/17): 4430es2panda, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.19-rc4 (eaa27f34e91a14cdceed26ed6c6793ec1d186115)): text data bsstotal kernel +127200+1272 omap1_defconfig +1272 -80+1264 omap1_defconfig_1510innovator_only +130400+1304 omap1_defconfig_5912osk_only +1748 +3840+2132 multi_v7_defconfig +5680 +160+5696 omap2plus_defconfig +1324 +240+1348 omap2plus_defconfig_2430sdp_only +1224 +160+1240 omap2plus_defconfig_am33xx_only +1288 -240+1264 omap2plus_defconfig_am43xx_only +5744 +240+5768 omap2plus_defconfig_cpupm +5564 +320+5596 omap2plus_defconfig_dra7xx_only +62000 +620 omap2plus_defconfig_n800_multi_omap2xxx +580 +80 +588 omap2plus_defconfig_n800_only_a +1648 -80+1640 omap2plus_defconfig_no_pm +1380 -80+1372 omap2plus_defconfig_omap2_4_only +1420 +160+1436 omap2plus_defconfig_omap3_4_only +5560 +80+5568 omap2plus_defconfig_omap5_only +844 -8 -128 +708 rmk_omap3430_ldp_allnoconfig +5064 +240+5088 rmk_omap3430_ldp_oldconfig +6920 -112
Re: 3.19 on Nokia n900: audio quality awful
Hi! If you have any idea about playback problems, help would be still welcome. I'll have to do bisect, otherwise, and it will not be easy. In 3.18, sound is nice and clear. In 3.19, sound is unusable. It produces nasty tone when it should be quiet, and there's at least as much noise as is sound. Unfortunately, list of mixers also changed (and there's cca 120 settings), but a) it does not work with the old list and b) nothing I could figure out did make the sound usable. Some setting resulted in even more noise. Any idea what could have caused it? I tried audio recording this time. In 2.6.28-nokia, it is neccessary to set Input select na digital mic, then it works. Input select being in playback option makes it easy to miss. In 3.18 and 3.19-rc3, all I can record are zeros. Does playback/recording work for you on OMAP 3430-based machines? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bluetooth: Add hci_h4p driver
Hi! Add HCI driver for H4 with Nokia extensions. This device is used on Nokia N900 cell phone. Older version of this driver lived in staging, before being reverted in a4102f90e87cfaa3fdbed6fdf469b23f0eeb4bfd . Any news here? I'd like the driver to hit 3.20... Pavel Kconfig | 10 Makefile |4 nokia_core.c | 1149 +++ nokia_fw.c | 99 + nokia_h4p.h | 214 ++ nokia_uart.c | 171 7 files changed, 1667 insertions(+) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
beaglebone black: is mem=... broken?
Boot hangs when passing mem=256M to a 3.16 kernel (but i was able to reproduce
it with multi_v7_defconfig on a 3.19rcX kernel too):
80e6d694: 0024 65746e49 6c616e72..$.Internal
80e6d6a4: 72726520 203a726f 73706f4f 2035203a error: Oops: 5
80e6d6b4: 5d31235b 504d5320 4d524120 [#1] SMP ARM
80e6d6c4: 0012 75646f4dModu
80e6d6d4: 2073656c 6b6e696c 69206465 3a6eles linked in:..
80e6d6e4:
80e6d6f4: 6f4320300 Co
80e6d704: 203a6d6d 70617773 20726570 20746f4emm: swapper Not
80e6d714: 6e696174 20646574 36312e33 322d302etainted 3.16.0-2
80e6d724: 65672d38 6972656e 33232063 62552d388-generic #38-Ub
80e6d734: 75746e75 002duntu..-.
80e6d744: 6b736174 3063203a 61313964task: c0d91a
80e6d754: 74203832 63203a69 34386430 2030303028 ti: c0d84000
80e6d764: 6b736174 3a69742e 64306320 30303438task.ti: c0d8400
80e6d774: 0030 00220..
80e6d784: 69204350 74612073 74646620PC is at fdt
80e6d794: 6568635f 685f6b63 65646165 78302b72_check_header+0x
80e6d7a4: 78302f30 3437 0/0x74..
80e6d7b4: 74612073s at
80e6d7c4: 755f5f20 616c666e 6e657474 7665645f __unflatten_dev
80e6d7d4: 5f656369 65657274 3778302b 78302f38ice_tree+0x78/0x
80e6d7e4: 00306132 2a0.
80e6d7f4: 65323930092e
80e6d804: 3e383064 2020205d 20726c20 3c5b203ad08]lr : [
80e6d814: 64373063 34303335 20205d3e 73702020c07d5304]ps
80e6d824: 36203a72 30303030 0a333931 3a207073r: 6193.sp :
80e6d834: 64306320 33663538 69202030 203a2070 c0d85f30 ip :
80e6d844: 31663038 37616638 70662020 63203a2080f18fa7 fp : c
80e6d854: 33666530 00343661 0ef3a64.
80e6d864:
80e6d874: 36623063c0b6
80e6d884: 30393730 38722020 63203a20 613264300790 r8 : c0d2a
80e6d894: 00383435 548.
80e6d8a4:
80e6d8b4: 303030355000
80e6d8c4: 35722020 63203a20 33366530 20306330 r5 : c0e630c0
80e6d8d4: 20347220 3063203a 30333665 3063 r4 : c0e630c0..
80e6d8e4:
80e6d8f4: 722020300 r
80e6d904: 203a2032 30303030 30303030 317220202 : r1
80e6d914: 63203a20 30316630 20633231 20307220 : c0f1012c r0
80e6d924: 6663203a 3035 3030 : cfff5000..
80e6d934: 67616c46Flag
80e6d944: 6e203a73 2076435a 51524920 666f2073s: nZCv IRQs of
80e6d954: 46202066 20735149 20206e6f 65646f4df FIQs on Mode
80e6d964: 43565320 2032335f 41534920 4d524120 SVC_32 ISA ARM
80e6d974: 65532020 6e656d67 656b2074 6c656e72 Segment kernel
Another thing that i noticed was that we actually pass 256M as the physical
memory, while the beaglebone black has 512M - is the dt live patched by the
bootloader before being passed to the kernel?
dtc -I dtb ./arch/arm/boot/dts/am335x-boneblack.dtb
...
memory {
device_type = memory;
reg = 0x8000 0x1000;
};
...
--
bye,
p.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] mfd: tps65218: make INT1 our status_base register
On Fri, 26 Dec 2014, Felipe Balbi wrote:
If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.
Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: sta...@vger.kernel.org # v3.15+
Cc: Keerthy j-keer...@ti.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/tps65218.c | 1 +
1 file changed, 1 insertion(+)
Sorry for the delay. It's difficult to get a WiFi signal 2000m up in
an Austrian mountain. :)
Applied now, thanks.
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 2243f75..d6b7643 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -204,6 +204,7 @@ static struct regmap_irq_chip tps65218_irq_chip = {
.num_regs = 2,
.mask_base = TPS65218_REG_INT_MASK1,
+ .status_base = TPS65218_REG_INT1,
};
static const struct of_device_id of_tps65218_match_table[] = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mfd: tps65218: make INT[12] and STATUS registers volatile
On Fri, 26 Dec 2014, Felipe Balbi wrote:
STATUS register can be modified by the HW, so we
should bypass cache because of that.
In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.
Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: sta...@vger.kernel.org # v3.15+
Cc: Keerthy j-keer...@ti.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/tps65218.c | 11 +++
1 file changed, 11 insertions(+)
Sorry for the delay. It's difficult to get a WiFi signal 2000m up in
an Austrian mountain. :)
Applied now, thanks.
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 0d256cb..2243f75 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -125,10 +125,21 @@ int tps65218_clear_bits(struct tps65218 *tps, unsigned
int reg,
}
EXPORT_SYMBOL_GPL(tps65218_clear_bits);
+static const struct regmap_range tps65218_yes_ranges[] = {
+ regmap_reg_range(TPS65218_REG_INT1, TPS65218_REG_INT2),
+ regmap_reg_range(TPS65218_REG_STATUS, TPS65218_REG_STATUS),
+};
+
+static const struct regmap_access_table tps65218_volatile_table = {
+ .yes_ranges = tps65218_yes_ranges,
+ .n_yes_ranges = ARRAY_SIZE(tps65218_yes_ranges),
+};
+
static struct regmap_config tps65218_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.cache_type = REGCACHE_RBTREE,
+ .volatile_table = tps65218_volatile_table,
};
static const struct regmap_irq tps65218_irqs[] = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beaglebone black: is mem=... broken?
On Sun, Jan 18, 2015 at 3:34 PM, Paolo Pisati p.pis...@gmail.com wrote:
Boot hangs when passing mem=256M to a 3.16 kernel (but i was able to reproduce
it with multi_v7_defconfig on a 3.19rcX kernel too):
80e6d694: 0024 65746e49 6c616e72..$.Internal
80e6d6a4: 72726520 203a726f 73706f4f 2035203a error: Oops: 5
80e6d6b4: 5d31235b 504d5320 4d524120 [#1] SMP ARM
80e6d6c4: 0012 75646f4dModu
80e6d6d4: 2073656c 6b6e696c 69206465 3a6eles linked in:..
80e6d6e4:
80e6d6f4: 6f4320300 Co
80e6d704: 203a6d6d 70617773 20726570 20746f4emm: swapper Not
80e6d714: 6e696174 20646574 36312e33 322d302etainted 3.16.0-2
80e6d724: 65672d38 6972656e 33232063 62552d388-generic #38-Ub
80e6d734: 75746e75 002duntu..-.
80e6d744: 6b736174 3063203a 61313964task: c0d91a
80e6d754: 74203832 63203a69 34386430 2030303028 ti: c0d84000
80e6d764: 6b736174 3a69742e 64306320 30303438task.ti: c0d8400
80e6d774: 0030 00220..
80e6d784: 69204350 74612073 74646620PC is at fdt
80e6d794: 6568635f 685f6b63 65646165 78302b72_check_header+0x
80e6d7a4: 78302f30 3437 0/0x74..
80e6d7b4: 74612073s at
The boot loader copied the DT to the end of real RAM, not to the end of
the 256 MiB block? Hence the kernel accesses unmapped memory
when checking the FDT header?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] media: i2c/adp1653: devicetree support for adp1653
On Sun 2015-01-04 10:43:52, Pavel Machek wrote: We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation. Signed-off-by: Pavel Machek pa...@ucw.cz Sakari? You are listed as adp1653 maintainer. Did you apply the patch? Is it going to be in 3.20? Thanks, Pavel --- Please apply, Pavel diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt b/Documentation/devicetree/bindings/media/i2c/adp1653.txt new file mode 100644 index 000..0fc28a9 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt @@ -0,0 +1,37 @@ +* Analog Devices ADP1653 flash LED driver -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
On 01/18/2015 12:33 PM, Pavel Machek wrote: Pavel, can you look into the omap4 thermal driver to see if it can be used ? After some fixes... yes, it seems to be same hardware. So this should be the way to go, but then we have others claim that it should not be done because the OMAP3 sensors are too unreliable to use for thermal decisions. Not really sure where that leaves us. I am kind of opposed to have similar drivers for similar chips in two different subsystems. Is it possible to add the patch below to the omap thermal driver and not use it for thermal decisions ? Well... noone forces you to enable the driver, and I don't think it will do any thermal decisions on N900 as it is ... so we should be ok. Plus, it seems to work reasonably well (say +- 5 C), so situation does not seem to be as bad as TI claims. Nokia was actually using it in production. Ok, I'll assume that omap3 support will be added to the omap thermal driver. Thanks, Guenter -- 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/4] Drop legacy support for omap3517
On Sun, Jan 18, 2015 at 10:02:17PM +0100, Pavel Machek wrote: He reported also some (still not fixed) regressions on n900. adp1653 flash driver does not have device tree bindings, yet. Patches were submitted, but I guess I'll need to push them some more. Yes, but that's not a regression, since mainline kernel does not load adp1653 when booted in legacy mode. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 1/7] ARM: OMAP2+: Remove unused ti81xx platform init code
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -82,16 +82,8 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (soc_is_am35xx()) {
Was it intentional that this patch also removed a test for am35xx
(rather than am335x) ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor
On Wed 2015-01-07 08:19:44, Guenter Roeck wrote: On Sat, Jan 03, 2015 at 10:18:58AM +0100, Pavel Machek wrote: On Mon 2014-12-29 11:04:48, Guenter Roeck wrote: On Mon, Dec 29, 2014 at 07:15:56PM +0100, Pavel Machek wrote: On Mon 2014-12-29 12:01:03, Nishanth Menon wrote: On Mon, Dec 29, 2014 at 11:52 AM, Grazvydas Ignotas nota...@gmail.com wrote: On Fri, Dec 26, 2014 at 2:34 PM, Sebastian Reichel s...@kernel.org wrote: OMAP34xx and OMAP36xx processors contain a register in the syscon area, which can be used to determine the SoCs temperature. This patch provides a DT based driver for the temperature sensor based on an older driver written by Peter De Schrijver for the Nokia N900 and N9. The sensor looks like an earlier iteration of sensors used in newer OMAPs, which are already supported by maybe drivers/thermal/ti-soc-thermal/ , maybe it would make sense to update that driver instead? Just to be clear - OMAP4 is the first time that the sensors were reliable enough to be used. When testing initial version of the patch, they seem to work very well in the omap3 case. Pavel, can you look into the omap4 thermal driver to see if it can be used ? After some fixes... yes, it seems to be same hardware. So this should be the way to go, but then we have others claim that it should not be done because the OMAP3 sensors are too unreliable to use for thermal decisions. Not really sure where that leaves us. I am kind of opposed to have similar drivers for similar chips in two different subsystems. Is it possible to add the patch below to the omap thermal driver and not use it for thermal decisions ? Well... noone forces you to enable the driver, and I don't think it will do any thermal decisions on N900 as it is ... so we should be ok. Plus, it seems to work reasonably well (say +- 5 C), so situation does not seem to be as bad as TI claims. Nokia was actually using it in production. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] cleanup ti-soc-thermal
Simplify code by removing goto's where they point to simple return.
Avoid confusing |= on error values.
Correct whitespace.
Signed-off-by: Pavel Machek pa...@ucw.cz
---
Please apply,
Pavel
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..2fde78c 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -103,19 +105,15 @@ do {
\
*/
static int ti_bandgap_power(struct ti_bandgap *bgp, bool on)
{
- int i, ret = 0;
+ int i;
- if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH)) {
- ret = -ENOTSUPP;
- goto exit;
- }
+ if (!TI_BANDGAP_HAS(bgp, POWER_SWITCH))
+ return -ENOTSUPP;
for (i = 0; i bgp-conf-sensor_count; i++)
/* active on 0 */
RMW_BITS(bgp, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
-
-exit:
- return ret;
+ return 0;
}
/**
@@ -263,18 +261,13 @@ static
int ti_bandgap_adc_to_mcelsius(struct ti_bandgap *bgp, int adc_val, int *t)
{
const struct ti_bandgap_data *conf = bgp-conf;
- int ret = 0;
/* look up for temperature in the table and return the temperature */
- if (adc_val conf-adc_start_val || adc_val conf-adc_end_val) {
- ret = -ERANGE;
- goto exit;
- }
+ if (adc_val conf-adc_start_val || adc_val conf-adc_end_val)
+ return -ERANGE;
*t = bgp-conf-conv_table[adc_val - conf-adc_start_val];
-
-exit:
- return ret;
+ return 0;
}
/**
@@ -295,16 +288,14 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp,
long temp, int *adc)
{
const struct ti_bandgap_data *conf = bgp-conf;
const int *conv_table = bgp-conf-conv_table;
- int high, low, mid, ret = 0;
+ int high, low, mid;
low = 0;
high = conf-adc_end_val - conf-adc_start_val;
mid = (high + low) / 2;
- if (temp conv_table[low] || temp conv_table[high]) {
- ret = -ERANGE;
- goto exit;
- }
+ if (temp conv_table[low] || temp conv_table[high])
+ return -ERANGE;
while (low high) {
if (temp conv_table[mid])
@@ -315,9 +306,7 @@ int ti_bandgap_mcelsius_to_adc(struct ti_bandgap *bgp, long
temp, int *adc)
}
*adc = conf-adc_start_val + low;
-
-exit:
- return ret;
+ return 0;
}
/**
@@ -343,13 +332,11 @@ int ti_bandgap_add_hyst(struct ti_bandgap *bgp, int
adc_val, int hyst_val,
*/
ret = ti_bandgap_adc_to_mcelsius(bgp, adc_val, temp);
if (ret 0)
- goto exit;
+ return ret;
temp += hyst_val;
ret = ti_bandgap_mcelsius_to_adc(bgp, temp, sum);
-
-exit:
return ret;
}
@@ -468,22 +455,18 @@ exit:
*/
static inline int ti_bandgap_validate(struct ti_bandgap *bgp, int id)
{
- int ret = 0;
-
if (!bgp || IS_ERR(bgp)) {
pr_err(%s: invalid bandgap pointer\n, __func__);
- ret = -EINVAL;
- goto exit;
+ return -EINVAL;
}
if ((id 0) || (id = bgp-conf-sensor_count)) {
dev_err(bgp-dev, %s: sensor id out of range (%d)\n,
__func__, id);
- ret = -ERANGE;
+ return -ERANGE;
}
-exit:
- return ret;
+ return 0;
}
/**
@@ -511,12 +494,10 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap
*bgp, int id, int val,
ret = ti_bandgap_validate(bgp, id);
if (ret)
- goto exit;
+ return ret;
- if (!TI_BANDGAP_HAS(bgp, TALERT)) {
- ret = -ENOTSUPP;
- goto exit;
- }
+ if (!TI_BANDGAP_HAS(bgp, TALERT))
+ return -ENOTSUPP;
ts_data = bgp-conf-sensors[id].ts_data;
tsr = bgp-conf-sensors[id].registers;
@@ -529,17 +510,15 @@ static int _ti_bandgap_write_threshold(struct ti_bandgap
*bgp, int id, int val,
}
if (ret)
- goto exit;
+ return ret;
ret = ti_bandgap_mcelsius_to_adc(bgp, val, adc_val);
if (ret 0)
- goto exit;
+ return ret;
spin_lock(bgp-lock);
ret = ti_bandgap_update_alert_threshold(bgp, id, adc_val, hot);
spin_unlock(bgp-lock);
-
-exit:
return ret;
}
@@ -582,7 +561,7 @@ static int _ti_bandgap_read_threshold(struct ti_bandgap
*bgp, int id,
temp = ti_bandgap_readl(bgp, tsr-bgap_threshold);
temp = (temp mask) __ffs(mask);
- ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, temp);
+ ret = ti_bandgap_adc_to_mcelsius(bgp, temp, temp);
if (ret) {
dev_err(bgp-dev,
Re: [PATCH] ti-soc-thermal: implement eocz bit to make driver useful on omap3
Hi! Ok, what do you suggest? AFAICT, without MODE_CONFIG, continuous ADC mode is not available, so we have to force it periodically, so this should be correct. I will have a better look and let you know. for now, adding a single read should not hurt ( but I will double check) Any news there? + if (ret) + return ret; + } + spin_lock(bgp-lock); temp = ti_bandgap_read_temp(bgp, id); spin_unlock(bgp-lock); - ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, temp); + ret = ti_bandgap_adc_to_mcelsius(bgp, temp, temp); this one should be part of your clean up patch Ok, can you apply the cleanup patch and I'll prepare one on the top of it? I mean, you should resend the cleanup patch including the above '|=' removal, as you are already doing in the cleanup patch. Ok, little patch-editing can not hurt :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] ti-soc-thermal: implement eocz bit to make driver useful on omap3
For omap3, proper implementation of eocz bit is needed. It was
actually a TODO in the driver.
Signed-off-by: Pavel Machek pa...@ucw.cz
---
No longer includes forced reading in single conversion mode; that will
be done as a separate patch.
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..2fde78c 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -917,7 +903,8 @@ void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp,
int id)
static int
ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
{
- u32 temp = 0, counter = 1000;
+ u32 counter = 1000;
+ struct temp_sensor_registers *tsr;
/* Select single conversion mode */
if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
@@ -925,16 +912,27 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int
id)
/* Start of Conversion = 1 */
RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
- /* Wait until DTEMP is updated */
- temp = ti_bandgap_read_temp(bgp, id);
- while ((temp == 0) --counter)
- temp = ti_bandgap_read_temp(bgp, id);
- /* REVISIT: Check correct condition for end of conversion */
+ /* Wait for EOCZ going up */
+ tsr = bgp-conf-sensors[id].registers;
+
+ while (--counter) {
+ if (ti_bandgap_readl(bgp, tsr-temp_sensor_ctrl)
+ tsr-bgap_eocz_mask)
+ break;
+ }
/* Start of Conversion = 0 */
RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
+ /* Wait for EOCZ going down */
+ counter = 1000;
+ while (--counter) {
+ if (!(ti_bandgap_readl(bgp, tsr-temp_sensor_ctrl)
+ tsr-bgap_eocz_mask))
+ break;
+ }
+
return 0;
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] ti-soc-thermal: request temperature periodically if hw can't do that itself
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..2fde78c 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -43,6 +43,8 @@
#include ti-bandgap.h
+static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id);
+
/*** Helper functions to access registers and their bitfields ***/
/**
@@ -852,14 +831,21 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp,
int id,
if (ret)
return ret;
+ if (!TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
+ ret = ti_bandgap_force_single_read(bgp, id);
+ if (ret)
+ return ret;
+ }
+
spin_lock(bgp-lock);
temp = ti_bandgap_read_temp(bgp, id);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] thermal: add omap3 support
Add support for omap3430 sensor. Tested on Nokia N900.
Fix help text to be closer to english.
Ifdefs in ti-bandgap.h are not neccessary, as users have #ifdefs,
already.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig
b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..65c478e 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -21,13 +21,28 @@ config TI_THERMAL
This includes trip points definitions, extrapolation rules and
CPU cooling device bindings.
+config OMAP3_THERMAL
+ bool Texas Instruments OMAP3 thermal support
+ depends on TI_SOC_THERMAL
+ depends on ARCH_OMAP3
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP3 SoC family. The current chips supported are:
+ - OMAP3430
+
+ OMAP3 chips normally don't need thermal management, and sensors in
+ this generation are not very accurate, nor they are very close to
+ the important hotspots.
+
+ Say 'N' here.
+
config OMAP4_THERMAL
bool Texas Instruments OMAP4 thermal support
depends on TI_SOC_THERMAL
depends on ARCH_OMAP4
help
If you say yes here you get thermal support for the Texas Instruments
- OMAP4 SoC family. The current chip supported are:
+ OMAP4 SoC family. The current chips supported are:
- OMAP4430
- OMAP4460
- OMAP4470
@@ -41,7 +56,7 @@ config OMAP5_THERMAL
depends on SOC_OMAP5
help
If you say yes here you get thermal support for the Texas Instruments
- OMAP5 SoC family. The current chip supported are:
+ OMAP5 SoC family. The current chips supported are:
- OMAP5430
This includes alert interrupts generation and also the TSHUT
@@ -53,7 +68,7 @@ config DRA752_THERMAL
depends on SOC_DRA7XX
help
If you say yes here you get thermal support for the Texas Instruments
- DRA752 SoC family. The current chip supported are:
+ DRA752 SoC family. The current chips supported are:
- DRA752
This includes alert interrupts generation and also the TSHUT
diff --git a/drivers/thermal/ti-soc-thermal/Makefile
b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..0f89bdf 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal.o
ti-soc-thermal-y := ti-bandgap.o
ti-soc-thermal-$(CONFIG_TI_THERMAL)+= ti-thermal-common.o
ti-soc-thermal-$(CONFIG_DRA752_THERMAL)+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL) += omap3-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 000..5cee2a35
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,103 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek pa...@ucw.cz
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Note
+ * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf Advisory
+ * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used
+ *
+ * Also TI says:
+ * Just be careful when you try to make thermal policy like decisions
+ * based on this sensor. Placement of the sensor w.r.t the actual logic
+ * generating heat has to be a factor as well. If you are just looking
+ * for an approximation temperature (thermometerish kind), you might be
+ * ok with this. I am not sure we'd find any TI data around this.. just a
+ * heads up.
+ */
+
+#include ti-thermal.h
+#include ti-bandgap.h
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = 0,
+ .bgap_soc_mask = BIT(8),
+ .bgap_eocz_mask = BIT(7),
+ .bgap_dtemp_mask = 0x7f,
+
+ .bgap_mode_ctrl = 0,
+ .mode_ctrl_mask = BIT(9),
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+ .min_freq = 32768,
+ .max_freq = 32768,
+
Re: [PATCH 0/4] Drop legacy support for omap3517
CCing Pavel Machek He reported also some (still not fixed) regressions on n900. adp1653 flash driver does not have device tree bindings, yet. Patches were submitted, but I guess I'll need to push them some more. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
