OMAP3630-ISP and MT9P031 Device Tree Help
I am trying to setup the device tree to enable a parallel camera interface as found on the LPD Dev Kit. The instructions I am using for the basis are: https://alaganraj.wordpress.com/2015/08/08/beagleboard-xm-camera-li-5m03-mt9p031-support-with-device-tree/ It I get the same results when I compile it into the kernel or as a module, but the errors are the same. When I modprobe it, I get: # modprobe omap3-isp omap3isp 480bc000.isp: parsing endpoint /ocp/isp@480bc000/ports/port@0/endpoint, interface 0 omap3isp 480bc000.isp: Revision 15.0 found iommu: Adding device 480bc000.isp to group 0 omap-iommu 480bd400.mmu: 480bd400.mmu: version 1.1 omap3isp 480bc000.isp: hist: using DMA channel dma0chan6 omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CCP2 was not initialized! omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CSI2a was not initialized! omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP CCDC was not initialized! omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP preview was not initialized! omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP resizer was not initialized! omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP AEWB was not initialized! omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP AF was not initialized! omap3isp 480bc000.isp: Entity type for entity OMAP3 ISP histogram was not initialized! # I then modprobe the mt9p031 driver, and it won't initialize, but it is detected. # modprobe mt9p031 [ 127.390808] 1-0048 supply vdd not found, using dummy regulator [ 127.398101] 1-0048 supply vaa not found, using dummy regulator [ 127.404907] omap3isp 480bc000.isp: isp_xclk_set_rate: cam_xclka set to 2160 Hz (div 8) [ 127.432861] mt9p031 1-0048: MT9P031 detected at address 0x48 [ 127.438873] omap3isp 480bc000.isp: Entity type for entity mt9p031 1-0048 was not initialized! # I can post my device tree if necessary, but it's basically like what's in the link above. Does anyone have any ideas on what I am doing wrong? adam -- 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 RFC v3 1/7] drm/edid: add function to help find SADs, DO NOT MERGE
From: Russell King - ARM Linux li...@arm.linux.org.uk
Add a function to find the start of the SADs in the ELD. This
complements the helper to retrieve the SAD count.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
This should already be coming in from drm-next.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
include/drm/drm_edid.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 7990501..53c53c4 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -348,6 +348,25 @@ static inline int drm_eld_mnl(const uint8_t *eld)
}
/**
+ * drm_eld_sad - Get ELD SAD structures.
+ * @eld: pointer to an eld memory structure with sad_count set
+ */
+static inline const uint8_t *drm_eld_sad(const uint8_t *eld)
+{
+ unsigned int ver, mnl;
+
+ ver = (eld[DRM_ELD_VER] DRM_ELD_VER_MASK) DRM_ELD_VER_SHIFT;
+ if (ver != 2 ver != 31)
+ return NULL;
+
+ mnl = drm_eld_mnl(eld);
+ if (mnl 16)
+ return NULL;
+
+ return eld + DRM_ELD_CEA_SAD(mnl, 0);
+}
+
+/**
* drm_eld_sad_count - Get ELD SAD count.
* @eld: pointer to an eld memory structure with sad_count set
*/
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mtd: nand: omap: Correct CONFIG_MTD_NAND_OMAP_BCH help message
The MTD_NAND_OMAP_BCH doesn't harm on legacy OMAP platforms so don't state that it should be disabled for them. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 1cb4b1b..dd10646 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -104,7 +104,7 @@ config MTD_NAND_OMAP_BCH locate and correct errors when using BCH ECC scheme. This offloads the cpu from doing ECC error searching and correction. However some legacy OMAP families like OMAP2xxx, OMAP3xxx do not have ELM engine - so they should not enable this config symbol. + so this is optional for them. config MTD_NAND_OMAP_BCH_BUILD def_tristate MTD_NAND_OMAP2 MTD_NAND_OMAP_BCH -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
Hi, On 12/05/14 12:12, Jyri Sarha wrote: Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 8921a7a..ecc2f50 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO - bool + bool HDMI audio support for OMAP4 + depends on OMAP4_DSS_HDMI + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP4 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. What does for full HDMI audio support mean? What's the partial support? =) Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
On 05/16/2014 01:52 PM, Tomi Valkeinen wrote: Hi, On 12/05/14 12:12, Jyri Sarha wrote: Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 8921a7a..ecc2f50 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO - bool + bool HDMI audio support for OMAP4 + depends on OMAP4_DSS_HDMI + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP4 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. What does for full HDMI audio support mean? What's the partial support? =) The hdmi driver provides a digital audio interface (DAI) which can be used to transmit audio over the HDMI cable. The ASoC DAI component driver provides just that functionality. A machine, platform, and (in this case a dummy) codec component driver is also needed for a complete ALSA device functionality. Anyway, I look into Mark's suggestion of instantiating all the necessary component drivers from the HDMI driver. Best regards, Jyri -- 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 10/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP5_DSS_HDMI_AUDIO
Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index ecc2f50..b28e175 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -90,8 +90,15 @@ config OMAP5_DSS_HDMI specification. config OMAP5_DSS_HDMI_AUDIO + bool HDMI audio support for OMAP5 depends on OMAP5_DSS_HDMI - bool + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP5 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. config OMAP2_DSS_SDI bool SDI support -- 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 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
Signed-off-by: Jyri Sarha jsa...@ti.com --- drivers/video/fbdev/omap2/dss/Kconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 8921a7a..ecc2f50 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO - bool + bool HDMI audio support for OMAP4 + depends on OMAP4_DSS_HDMI + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP4 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. config OMAP5_DSS_HDMI bool HDMI support for OMAP5 -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help to run latest kernel on DART-4460
* Michael Trimarchi mich...@amarulasolutions.com [140325 09:37]: Hi On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin andrey.krieger.ut...@gmail.com wrote: 2014-03-25 17:17 GMT+02:00 Michael Trimarchi mich...@amarulasolutions.com: I have already done somenthing like that more then 6 months ago. I was in a good state, What camera sensors are you using? Hi Michael, it is JAL-MIPI-OV5640. I think that I have all somewhere on top of 3.4. Can you contact on my email? I take it this issue has been resolved already? Probably you did not configure u-boot for the dtb? :) 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: Help to run latest kernel on DART-4460
Hi Tony On Fri, Apr 18, 2014 at 6:51 PM, Tony Lindgren t...@atomide.com wrote: * Michael Trimarchi mich...@amarulasolutions.com [140325 09:37]: Hi On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin andrey.krieger.ut...@gmail.com wrote: 2014-03-25 17:17 GMT+02:00 Michael Trimarchi mich...@amarulasolutions.com: I have already done somenthing like that more then 6 months ago. I was in a good state, What camera sensors are you using? Hi Michael, it is JAL-MIPI-OV5640. I think that I have all somewhere on top of 3.4. Can you contact on my email? I take it this issue has been resolved already? Probably you did not configure u-boot for the dtb? :) Yes, I have helped them. Nice should be test on a newest kernel. It should work but the device is in US and I help them remote using teamviewer so not so easy ;) Michael 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
Help to run latest kernel on DART-4460
Hi! We have a DART-4460 board which is based on TI OMAP4460. It is shipped by Variscite with linux kernel v3.4.27 (as /proc/config.gz states; uname -a shows Linux localhost.localdomain 3.4.0-1489-omap4 #28 SMP PREEMPT Wed Oct 30 10:58:36 IST 2013 armv7l armv7l armv7l GNU/Linux). We try to make it work with latest kernel, because we want to get video4linux interface to the cameras which are attached to the board by CSI interface. So we need drivers/staging/media/omap4iss/ stuff, if i understand it correct. This stuff is currently included in linux-stable master branch (but not in any tag) and in git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git The problem is that the kernel uImage we have prepared doesn't boot. The config of latest linux-stable kernel i have tried last time: https://gist.github.com/krieger-od/9a2c6bce5a69d22ca2dd The serial console output with it: https://gist.github.com/krieger-od/0fa0f6f6f597b10f95a4 The shipped kernel's config: https://gist.github.com/krieger-od/55b34ebe3571ae4dd875 The serial console output with kernel shipped by vendor: https://gist.github.com/krieger-od/32481d718e0519dd0bd9 Could anybody share a working config for recent enough kernel for this or similar hardware? Any comments? We appreciate any help. Thanks in advance. -- Andrey Utkin -- 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: Help to run latest kernel on DART-4460
Hi On Tue, Mar 25, 2014 at 4:00 PM, Andrey Utkin andrey.krieger.ut...@gmail.com wrote: Hi! We have a DART-4460 board which is based on TI OMAP4460. It is shipped by Variscite with linux kernel v3.4.27 (as /proc/config.gz states; uname -a shows Linux localhost.localdomain 3.4.0-1489-omap4 #28 SMP PREEMPT Wed Oct 30 10:58:36 IST 2013 armv7l armv7l armv7l GNU/Linux). We try to make it work with latest kernel, because we want to get video4linux interface to the cameras which are attached to the board by CSI interface. So we need drivers/staging/media/omap4iss/ stuff, if i understand it correct. This stuff is currently included in linux-stable master branch (but not in any tag) and in git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git The problem is that the kernel uImage we have prepared doesn't boot. The config of latest linux-stable kernel i have tried last time: https://gist.github.com/krieger-od/9a2c6bce5a69d22ca2dd The serial console output with it: https://gist.github.com/krieger-od/0fa0f6f6f597b10f95a4 The shipped kernel's config: https://gist.github.com/krieger-od/55b34ebe3571ae4dd875 The serial console output with kernel shipped by vendor: https://gist.github.com/krieger-od/32481d718e0519dd0bd9 Could anybody share a working config for recent enough kernel for this or similar hardware? Any comments? We appreciate any help. Thanks in advance. I have already done somenthing like that more then 6 months ago. I was in a good state, What camera sensors are you using? Michael -- Andrey Utkin -- 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 -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.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: Help to run latest kernel on DART-4460
2014-03-25 17:17 GMT+02:00 Michael Trimarchi mich...@amarulasolutions.com: I have already done somenthing like that more then 6 months ago. I was in a good state, What camera sensors are you using? Hi Michael, it is JAL-MIPI-OV5640. -- Andrey Utkin -- 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: Help to run latest kernel on DART-4460
Hi On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin andrey.krieger.ut...@gmail.com wrote: 2014-03-25 17:17 GMT+02:00 Michael Trimarchi mich...@amarulasolutions.com: I have already done somenthing like that more then 6 months ago. I was in a good state, What camera sensors are you using? Hi Michael, it is JAL-MIPI-OV5640. I think that I have all somewhere on top of 3.4. Can you contact on my email? Michael -- Andrey Utkin -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.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: Help needed USB hub disconnected at resume
On 03/06/2014 01:29 AM, Marc Murphy wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: 04 March 2014 23:43
To: Marc Murphy
Cc: 'ba...@ti.com'; 'Igor Grinberg'; Roger Quadros; linux-
o...@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
On Tue, Mar 04, 2014 at 11:05:58PM +, Marc Murphy wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: 04 March 2014 22:44
To: Marc Murphy
Cc: 'Igor Grinberg'; Roger Quadros; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
Hi,
On Tue, Mar 04, 2014 at 10:34:56PM +, Marc Murphy wrote:
static __init void tam3517_ehci_init(void) {
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(TAM3517_EHCI_RESET, OMAP_PIN_OUTPUT);
gpio_request(TAM3517_EHCI_RESET, USB_RESET);
gpio_direction_output(TAM3517_EHCI_RESET, 1);
gpio_export(TAM3517_EHCI_RESET, 0);
why are you exporting this gpio ?
It makes no difference whether I configure the GPIO or not.
gpio_export() is only to expose the gpio to sysfs. Check if that pin is
active
high or active low. Then what you need, most likely, is something like below:
gpio_direction_output(RESET, HIGH);
usleep_range(5, 200);
gpio_set_value(RESET, LOW);
(assuming active high here)
Thanks, the export was for sysfs so that I could toggle the state myself to
debug. The reference has now been removed and the toggling left to the
driver (ehci)
Igor, I have been looking at the ehci driver and the reset pin of the 3320 is
toggled at initialisation but there is no resetting when resuming from sleep.
I have created a resume function;
There should be no need to reset the PHY during suspend/resume.
Can you please try your board on v3.13? A lot of cleanup has been done since
3.4.
cheers,
-roger
static void ehci_hcd_omap_resume(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ehci_hcd_omap_platform_data *pdata = dev-platform_data;
if (pdata-phy_reset) {
if (gpio_is_valid(pdata-reset_gpio_port[0]))
gpio_set_value(pdata-reset_gpio_port[0], 0);
if (gpio_is_valid(pdata-reset_gpio_port[1]))
gpio_set_value(pdata-reset_gpio_port[1], 0);
/* Hold the PHY in RESET for enough time till DIR is high */
udelay(100);
}
if (pdata-phy_reset) {
/* Hold the PHY in RESET for enough time till
* PHY is settled and ready
*/
udelay(10);
if (gpio_is_valid(pdata-reset_gpio_port[0]))
gpio_set_value(pdata-reset_gpio_port[0], 1);
if (gpio_is_valid(pdata-reset_gpio_port[1]))
gpio_set_value(pdata-reset_gpio_port[1], 1);
}
}
And linked in the static struct platform_driver ehci_hcd_omap_driver = {
.resume = ehci_hcd_omap_resume,
It calls the function at resume and I can see the line toggle on the scope
but still the same response from the driver of disconnecting the hub.
I have even stepped through ehci_bus_resume (struct usb_hcd *hcd) and it all
seems to be OK with the bringup.
Is there any way to enable more debug so that I can see the path through the
pm and hci code ?
I have enabled dynamic debug in the kernel but when I pass the dyndbg modules
on the command line I don't seem to get any additional output... e.g.
rootfstype=nfs ip=dhcp nohlt no_console_suspend=1 dyndbg= module ehci_hcd +p
; module uhci_hcd +p ; module ohci_hcd +p rw
Marc
--
balbi
--
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: Help needed USB hub disconnected at resume
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: 04 March 2014 23:43
To: Marc Murphy
Cc: 'ba...@ti.com'; 'Igor Grinberg'; Roger Quadros; linux-
o...@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
On Tue, Mar 04, 2014 at 11:05:58PM +, Marc Murphy wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: 04 March 2014 22:44
To: Marc Murphy
Cc: 'Igor Grinberg'; Roger Quadros; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
Hi,
On Tue, Mar 04, 2014 at 10:34:56PM +, Marc Murphy wrote:
static __init void tam3517_ehci_init(void) {
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(TAM3517_EHCI_RESET, OMAP_PIN_OUTPUT);
gpio_request(TAM3517_EHCI_RESET, USB_RESET);
gpio_direction_output(TAM3517_EHCI_RESET, 1);
gpio_export(TAM3517_EHCI_RESET, 0);
why are you exporting this gpio ?
It makes no difference whether I configure the GPIO or not.
gpio_export() is only to expose the gpio to sysfs. Check if that pin is active
high or active low. Then what you need, most likely, is something like below:
gpio_direction_output(RESET, HIGH);
usleep_range(5, 200);
gpio_set_value(RESET, LOW);
(assuming active high here)
Thanks, the export was for sysfs so that I could toggle the state myself to
debug. The reference has now been removed and the toggling left to the driver
(ehci)
Igor, I have been looking at the ehci driver and the reset pin of the 3320 is
toggled at initialisation but there is no resetting when resuming from sleep.
I have created a resume function;
static void ehci_hcd_omap_resume(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ehci_hcd_omap_platform_data *pdata = dev-platform_data;
if (pdata-phy_reset) {
if (gpio_is_valid(pdata-reset_gpio_port[0]))
gpio_set_value(pdata-reset_gpio_port[0], 0);
if (gpio_is_valid(pdata-reset_gpio_port[1]))
gpio_set_value(pdata-reset_gpio_port[1], 0);
/* Hold the PHY in RESET for enough time till DIR is high */
udelay(100);
}
if (pdata-phy_reset) {
/* Hold the PHY in RESET for enough time till
* PHY is settled and ready
*/
udelay(10);
if (gpio_is_valid(pdata-reset_gpio_port[0]))
gpio_set_value(pdata-reset_gpio_port[0], 1);
if (gpio_is_valid(pdata-reset_gpio_port[1]))
gpio_set_value(pdata-reset_gpio_port[1], 1);
}
}
And linked in the static struct platform_driver ehci_hcd_omap_driver = {
.resume = ehci_hcd_omap_resume,
It calls the function at resume and I can see the line toggle on the scope but
still the same response from the driver of disconnecting the hub.
I have even stepped through ehci_bus_resume (struct usb_hcd *hcd) and it all
seems to be OK with the bringup.
Is there any way to enable more debug so that I can see the path through the pm
and hci code ?
I have enabled dynamic debug in the kernel but when I pass the dyndbg modules
on the command line I don't seem to get any additional output... e.g.
rootfstype=nfs ip=dhcp nohlt no_console_suspend=1 dyndbg= module ehci_hcd +p ;
module uhci_hcd +p ; module ohci_hcd +p rw
Marc
--
balbi
--
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: Help needed USB hub disconnected at resume
Hi Igor The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port via the DUP_P and DUP_N pins. There is a reset applied to the chip at power on. If the reset signal is sw controllable, you might want to toggle it before the EHCI controller resumes. The reset control is currently connected to the system reset signal that is generated at power up. I will disconnect it and try mapping it to a GPIO. There is also a USB phy on the way from EHCI controller to the hub. You might also want to check if the phy resumes correctly. Which phy do you use and how is it reset? From what I can see the USB2513B IC has the Phy built in and is connected directly to the AM3517. I am having the hardware engineer look into it but from what I can see on the circuit diagram its a direct connection. Regards Marc Regards Marc From: Igor Grinberg [grinb...@compulab.co.il] Sent: 03 March 2014 12:16 To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org Subject: Re: Help needed USB hub disconnected at resume On 03/03/14 13:06, Roger Quadros wrote: Hi Marc, On 03/03/2014 12:04 PM, Marc Murphy wrote: Hi, I am using the latest stable 3.4.80 kernel with some changes to get the EMAC Phy to initialise correctly after a suspend/resume. The platform is AM3517 with most of the system working nice and smoothly. I have 1 issue though and need some advice/help to get the system to use the USB hub I have connected to the EHCI controller after a suspend to memory and resume. At boot all is recognised; [1.486816] usbcore: registered new interface driver cdc_ether [1.493255] usbcore: registered new interface driver cdc_ncm [1.499450] usbcore: registered new interface driver qmi_wwan [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.574035] usb usb1: Product: OMAP-EHCI Host Controller [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd [2.585296] usb usb1: SerialNumber: ehci-omap.0 [2.591278] hub 1-0:1.0: USB hub found [2.595306] hub 1-0:1.0: 3 ports detected And I can see everything OK. # lsusb Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. # # # echo mem /sys/power/state [ 73.736572] PM: Syncing filesystems ... done. [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle [ 73.968872] PM: suspend of devices complete after 170.410 msecs [ 73.975433] PM: late suspend of devices complete after 0.305 msecs [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 [ 83.436737] Could not enter target state in pm_suspend [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs [ 83.450164] PM: early resume of devices complete after 0.274 msecs [ 83.457336] 6Waiting for PHY clock good... [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 84.771881] PM: resume of devices complete after 1315.185 msecs [ 84.778472] Restarting tasks ... [ 84.782379] usb 1-1: USB disconnect, device number 2 [ 84.790557] done. [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device ermitted [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full # # # lsusb Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # Is there any relevant patch out there that would address the issue that I see ? Does
RE: Help needed USB hub disconnected at resume
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Igor Grinberg
Sent: 04 March 2014 06:44
To: Marc Murphy; Roger Quadros; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
On 03/03/14 16:11, Marc Murphy wrote:
Hi Igor
The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller
port via the DUP_P and DUP_N pins. There is a reset applied to the chip at
power on.
If the reset signal is sw controllable, you might want to toggle it before the
EHCI controller resumes.
There is also a USB phy on the way from EHCI controller to the hub.
You might also want to check if the phy resumes correctly.
Which phy do you use and how is it reset?
I have now had a look with the schematics and the hardware engineer.
The AM3517 has a PHY connected and it is a SMSC USB3320. The device has a
reset connection via GPIO_25.
I have it configured as follows
#define TAM3517_EHCI_RESET 25
static const struct usbhs_omap_board_data tam3517_ehci_pdata __initconst = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
.phy_reset = true,
.reset_gpio_port[0] = TAM3517_EHCI_RESET,
.reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL
};
static __init void tam3517_ehci_init(void)
{
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(TAM3517_EHCI_RESET, OMAP_PIN_OUTPUT);
gpio_request(TAM3517_EHCI_RESET, USB_RESET);
gpio_direction_output(TAM3517_EHCI_RESET, 1);
gpio_export(TAM3517_EHCI_RESET, 0);
msleep(100);
gpio_set_value(TAM3517_EHCI_RESET, 1);
usbhs_init(tam3517_ehci_pdata);
}
I have tried without the phy reset control but stull get the same behaviour.
I have asked for some tap wires onto the control signals for the Phy and I will
have a look with a scope to make sure the pin is toggled correctly.
If you see anything wrong with the initialisation then please let me know.
Thanks
Marc
Regards
Marc
From: Igor Grinberg [grinb...@compulab.co.il]
Sent: 03 March 2014 12:16
To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
On 03/03/14 13:06, Roger Quadros wrote:
Hi Marc,
On 03/03/2014 12:04 PM, Marc Murphy wrote:
Hi,
I am using the latest stable 3.4.80 kernel with some changes to get the
EMAC Phy to initialise correctly after a suspend/resume. The platform is
AM3517 with most of the system working nice and smoothly. I have 1 issue
though and need some advice/help to get the system to use the USB hub I
have connected to the EHCI controller after a suspend to memory and
resume.
At boot all is recognised;
[1.486816] usbcore: registered new interface driver cdc_ether
[1.493255] usbcore: registered new interface driver cdc_ncm
[1.499450] usbcore: registered new interface driver qmi_wwan
[1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[1.513580] ehci-omap.0 supply hsusb0 not found, using dummy
regulator
[2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
[2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned
bus number 1
[2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
[2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
[2.559295] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002
[2.566436] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[2.574035] usb usb1: Product: OMAP-EHCI Host Controller
[2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd
[2.585296] usb usb1: SerialNumber: ehci-omap.0
[2.591278] hub 1-0:1.0: USB hub found
[2.595306] hub 1-0:1.0: 3 ports detected
And I can see everything OK.
# lsusb
Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA
Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root
hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc.
#
#
# echo mem /sys/power/state
[ 73.736572] PM: Syncing filesystems ... done.
[ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds)
done.
[ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle
[ 73.968872] PM: suspend of devices complete after 170.410 msecs
[ 73.975433] PM: late suspend of devices complete after 0.305 msecs
[ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs
[ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1
[ 83.436737] Could not enter target state in pm_suspend
Re: Help needed USB hub disconnected at resume
On Tue, Mar 04, 2014 at 11:05:58PM +, Marc Murphy wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: 04 March 2014 22:44
To: Marc Murphy
Cc: 'Igor Grinberg'; Roger Quadros; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume
Hi,
On Tue, Mar 04, 2014 at 10:34:56PM +, Marc Murphy wrote:
static __init void tam3517_ehci_init(void) {
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(TAM3517_EHCI_RESET, OMAP_PIN_OUTPUT);
gpio_request(TAM3517_EHCI_RESET, USB_RESET);
gpio_direction_output(TAM3517_EHCI_RESET, 1);
gpio_export(TAM3517_EHCI_RESET, 0);
why are you exporting this gpio ?
It makes no difference whether I configure the GPIO or not.
gpio_export() is only to expose the gpio to sysfs. Check if that pin is
active high or active low. Then what you need, most likely, is something
like below:
gpio_direction_output(RESET, HIGH);
usleep_range(5, 200);
gpio_set_value(RESET, LOW);
(assuming active high here)
--
balbi
signature.asc
Description: Digital signature
Help needed USB hub disconnected at resume
Hi, I am using the latest stable 3.4.80 kernel with some changes to get the EMAC Phy to initialise correctly after a suspend/resume. The platform is AM3517 with most of the system working nice and smoothly. I have 1 issue though and need some advice/help to get the system to use the USB hub I have connected to the EHCI controller after a suspend to memory and resume. At boot all is recognised; [1.486816] usbcore: registered new interface driver cdc_ether [1.493255] usbcore: registered new interface driver cdc_ncm [1.499450] usbcore: registered new interface driver qmi_wwan [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.574035] usb usb1: Product: OMAP-EHCI Host Controller [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd [2.585296] usb usb1: SerialNumber: ehci-omap.0 [2.591278] hub 1-0:1.0: USB hub found [2.595306] hub 1-0:1.0: 3 ports detected And I can see everything OK. # lsusb Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. # # # echo mem /sys/power/state [ 73.736572] PM: Syncing filesystems ... done. [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle [ 73.968872] PM: suspend of devices complete after 170.410 msecs [ 73.975433] PM: late suspend of devices complete after 0.305 msecs [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 [ 83.436737] Could not enter target state in pm_suspend [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs [ 83.450164] PM: early resume of devices complete after 0.274 msecs [ 83.457336] 6Waiting for PHY clock good... [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 84.771881] PM: resume of devices complete after 1315.185 msecs [ 84.778472] Restarting tasks ... [ 84.782379] usb 1-1: USB disconnect, device number 2 [ 84.790557] done. [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device ermitted [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full # # # lsusb Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # Is there any relevant patch out there that would address the issue that I see ? Kind Regards Marc -- 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: Help needed USB hub disconnected at resume
Hi Marc, On 03/03/2014 12:04 PM, Marc Murphy wrote: Hi, I am using the latest stable 3.4.80 kernel with some changes to get the EMAC Phy to initialise correctly after a suspend/resume. The platform is AM3517 with most of the system working nice and smoothly. I have 1 issue though and need some advice/help to get the system to use the USB hub I have connected to the EHCI controller after a suspend to memory and resume. At boot all is recognised; [1.486816] usbcore: registered new interface driver cdc_ether [1.493255] usbcore: registered new interface driver cdc_ncm [1.499450] usbcore: registered new interface driver qmi_wwan [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.574035] usb usb1: Product: OMAP-EHCI Host Controller [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd [2.585296] usb usb1: SerialNumber: ehci-omap.0 [2.591278] hub 1-0:1.0: USB hub found [2.595306] hub 1-0:1.0: 3 ports detected And I can see everything OK. # lsusb Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. # # # echo mem /sys/power/state [ 73.736572] PM: Syncing filesystems ... done. [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle [ 73.968872] PM: suspend of devices complete after 170.410 msecs [ 73.975433] PM: late suspend of devices complete after 0.305 msecs [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 [ 83.436737] Could not enter target state in pm_suspend [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs [ 83.450164] PM: early resume of devices complete after 0.274 msecs [ 83.457336] 6Waiting for PHY clock good... [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 84.771881] PM: resume of devices complete after 1315.185 msecs [ 84.778472] Restarting tasks ... [ 84.782379] usb 1-1: USB disconnect, device number 2 [ 84.790557] done. [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device ermitted [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full # # # lsusb Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # Is there any relevant patch out there that would address the issue that I see ? Does this happen because of OFF mode? Can you please try the tests with off mode disabled? e.g. mount -t debugfs none /sys/kernel/debug echo 0 /sys/kernel/debug/pm_debug/enable_off_mode suspend resume Also please send the output of /sys/kernel/debug/pm_debug/count before suspend and after resume. Thanks. cheers, -roger -- 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: Help needed USB hub disconnected at resume
On 03/03/14 13:06, Roger Quadros wrote: Hi Marc, On 03/03/2014 12:04 PM, Marc Murphy wrote: Hi, I am using the latest stable 3.4.80 kernel with some changes to get the EMAC Phy to initialise correctly after a suspend/resume. The platform is AM3517 with most of the system working nice and smoothly. I have 1 issue though and need some advice/help to get the system to use the USB hub I have connected to the EHCI controller after a suspend to memory and resume. At boot all is recognised; [1.486816] usbcore: registered new interface driver cdc_ether [1.493255] usbcore: registered new interface driver cdc_ncm [1.499450] usbcore: registered new interface driver qmi_wwan [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.574035] usb usb1: Product: OMAP-EHCI Host Controller [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd [2.585296] usb usb1: SerialNumber: ehci-omap.0 [2.591278] hub 1-0:1.0: USB hub found [2.595306] hub 1-0:1.0: 3 ports detected And I can see everything OK. # lsusb Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. # # # echo mem /sys/power/state [ 73.736572] PM: Syncing filesystems ... done. [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle [ 73.968872] PM: suspend of devices complete after 170.410 msecs [ 73.975433] PM: late suspend of devices complete after 0.305 msecs [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 [ 83.436737] Could not enter target state in pm_suspend [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs [ 83.450164] PM: early resume of devices complete after 0.274 msecs [ 83.457336] 6Waiting for PHY clock good... [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 84.771881] PM: resume of devices complete after 1315.185 msecs [ 84.778472] Restarting tasks ... [ 84.782379] usb 1-1: USB disconnect, device number 2 [ 84.790557] done. [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device ermitted [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full # # # lsusb Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # Is there any relevant patch out there that would address the issue that I see ? Does this happen because of OFF mode? Can you please try the tests with off mode disabled? e.g. mount -t debugfs none /sys/kernel/debug echo 0 /sys/kernel/debug/pm_debug/enable_off_mode suspend resume AFAIK, AM3517 does not have OFF mode. We had something similar with runtime pm... It might be useful to know which hub is this and how is it connected... Also please send the output of /sys/kernel/debug/pm_debug/count before suspend and after resume. Thanks. -- Regards, Igor. -- 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: Help needed USB hub disconnected at resume
Hi Igor The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port via the DUP_P and DUP_N pins. There is a reset applied to the chip at power on. Regards Marc From: Igor Grinberg [grinb...@compulab.co.il] Sent: 03 March 2014 12:16 To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org Subject: Re: Help needed USB hub disconnected at resume On 03/03/14 13:06, Roger Quadros wrote: Hi Marc, On 03/03/2014 12:04 PM, Marc Murphy wrote: Hi, I am using the latest stable 3.4.80 kernel with some changes to get the EMAC Phy to initialise correctly after a suspend/resume. The platform is AM3517 with most of the system working nice and smoothly. I have 1 issue though and need some advice/help to get the system to use the USB hub I have connected to the EHCI controller after a suspend to memory and resume. At boot all is recognised; [1.486816] usbcore: registered new interface driver cdc_ether [1.493255] usbcore: registered new interface driver cdc_ncm [1.499450] usbcore: registered new interface driver qmi_wwan [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.574035] usb usb1: Product: OMAP-EHCI Host Controller [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd [2.585296] usb usb1: SerialNumber: ehci-omap.0 [2.591278] hub 1-0:1.0: USB hub found [2.595306] hub 1-0:1.0: 3 ports detected And I can see everything OK. # lsusb Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. # # # echo mem /sys/power/state [ 73.736572] PM: Syncing filesystems ... done. [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle [ 73.968872] PM: suspend of devices complete after 170.410 msecs [ 73.975433] PM: late suspend of devices complete after 0.305 msecs [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 [ 83.436737] Could not enter target state in pm_suspend [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs [ 83.450164] PM: early resume of devices complete after 0.274 msecs [ 83.457336] 6Waiting for PHY clock good... [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 84.771881] PM: resume of devices complete after 1315.185 msecs [ 84.778472] Restarting tasks ... [ 84.782379] usb 1-1: USB disconnect, device number 2 [ 84.790557] done. [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device ermitted [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full # # # lsusb Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # Is there any relevant patch out there that would address the issue that I see ? Does this happen because of OFF mode? Can you please try the tests with off mode disabled? e.g. mount -t debugfs none /sys/kernel/debug echo 0 /sys/kernel/debug/pm_debug/enable_off_mode suspend resume AFAIK, AM3517 does not have OFF mode. We had something similar with runtime pm... It might be useful to know which hub is this and how is it connected... Also please send the output of /sys/kernel/debug/pm_debug/count before suspend and after resume. Thanks. -- Regards, Igor. -- 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: Help needed USB hub disconnected at resume
On 03/03/14 16:11, Marc Murphy wrote: Hi Igor The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port via the DUP_P and DUP_N pins. There is a reset applied to the chip at power on. If the reset signal is sw controllable, you might want to toggle it before the EHCI controller resumes. There is also a USB phy on the way from EHCI controller to the hub. You might also want to check if the phy resumes correctly. Which phy do you use and how is it reset? Regards Marc From: Igor Grinberg [grinb...@compulab.co.il] Sent: 03 March 2014 12:16 To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org Subject: Re: Help needed USB hub disconnected at resume On 03/03/14 13:06, Roger Quadros wrote: Hi Marc, On 03/03/2014 12:04 PM, Marc Murphy wrote: Hi, I am using the latest stable 3.4.80 kernel with some changes to get the EMAC Phy to initialise correctly after a suspend/resume. The platform is AM3517 with most of the system working nice and smoothly. I have 1 issue though and need some advice/help to get the system to use the USB hub I have connected to the EHCI controller after a suspend to memory and resume. At boot all is recognised; [1.486816] usbcore: registered new interface driver cdc_ether [1.493255] usbcore: registered new interface driver cdc_ncm [1.499450] usbcore: registered new interface driver qmi_wwan [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.574035] usb usb1: Product: OMAP-EHCI Host Controller [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd [2.585296] usb usb1: SerialNumber: ehci-omap.0 [2.591278] hub 1-0:1.0: USB hub found [2.595306] hub 1-0:1.0: 3 ports detected And I can see everything OK. # lsusb Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. # # # echo mem /sys/power/state [ 73.736572] PM: Syncing filesystems ... done. [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle [ 73.968872] PM: suspend of devices complete after 170.410 msecs [ 73.975433] PM: late suspend of devices complete after 0.305 msecs [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 [ 83.436737] Could not enter target state in pm_suspend [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs [ 83.450164] PM: early resume of devices complete after 0.274 msecs [ 83.457336] 6Waiting for PHY clock good... [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 84.771881] PM: resume of devices complete after 1315.185 msecs [ 84.778472] Restarting tasks ... [ 84.782379] usb 1-1: USB disconnect, device number 2 [ 84.790557] done. [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device ermitted [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full # # # lsusb Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # Is there any relevant patch out there that would address the issue that I see ? Does this happen because of OFF mode? Can you please try the tests with off mode disabled? e.g. mount -t debugfs none /sys/kernel/debug echo 0 /sys/kernel/debug/pm_debug/enable_off_mode suspend resume AFAIK, AM3517 does not have OFF mode. We had something similar with runtime pm... It might be useful to know which hub is this and how
Re: Help running latest linux-omap kernel on Nokia N810
On 2014-02-27 07:19, Tomi Valkeinen wrote: On 26/02/14 23:29, Aaro Koskinen wrote: First the bad news: display support is not in the mainline kernel. Also since linux-omap tree follows the mainline, it's not there either anymore. Tomi removed the n8x0 panel driver some time ago (I don't know why), but even then it wasn't working as the platform data failed to set up some It would've been a big effort to keep the panel driver compiling, as we moved to a new display driver architecture. And, as it wasn't working anyway, I deemed it simpler to just remove it. I have no objections to add it back, but it needs to be split into two separate drivers, blizzard encoder driver and the panel driver. The RFBI driver also probably needs some love. And, of course, DT support for all those. In theory, RFBI is relatively simple. If I recall right, the panel is also quite simple, although it still needs to be controlled via SPI. Blizzard was a bit more complex one, but perhaps most of its features can be just left out. But getting all those three working fine without being able to make any measurements between the components, well, one might needs some luck there =). I do have N800 and N810 (no serial mods), so I might be able to give some help there at some point, if I'm able to boot the board with usb gadget ethernet (which hasn't been working for me for omap3 for some time). Hi Tomi, In the following commit it states that you ported the old blizzard driver to the new omapdss driver: commit fdcb68884b3b0def9cc410d07adbafe7c3a9e537 Author: Tomi Valkeinen tomi.valkei...@ti.com Date: Tue May 10 17:31:20 2011 +0300 OMAPFB: remove old blizzard driver N8x0's blizzard driver has been ported to new omapdss driver, so we can now remove the old blizzard driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Did that driver work on the N810 at that point? If I look at the kernel tree at that point in time would all the components be there? It would make it easier if I had a starting point as I don't have any documentation so reading the old source code is the only way I can figure out how things work(ed). Regards, Leigh. -- 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: Help running latest linux-omap kernel on Nokia N810
On 27/02/14 10:19, Leigh Brown wrote: In the following commit it states that you ported the old blizzard driver to the new omapdss driver: commit fdcb68884b3b0def9cc410d07adbafe7c3a9e537 Author: Tomi Valkeinen tomi.valkei...@ti.com Date: Tue May 10 17:31:20 2011 +0300 OMAPFB: remove old blizzard driver N8x0's blizzard driver has been ported to new omapdss driver, so we can now remove the old blizzard driver. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Did that driver work on the N810 at that point? If I look at the kernel tree at that point in time would all the components be there? It would make it easier if I had a starting point as I don't have any documentation so reading the old source code is the only way I can figure out how things work(ed). Yes, that one worked, but... if I recall right, it didn't work in the mainline version. Or more precisely, the mainline kernel didn't work on N800 at all (at least for me). When I did the porting (and if my memory works right) I had a big pile of N800 patches on top of the mainline to get the board booting. And on top of that, I made the new blizzard driver. In fact, I possibly have the branch which I used in my backup repository. I pushed it to: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/n800-39 However, looking at the log, it doesn't contain anything else than DSS patches. So... Maybe that branch itself doesn't boot, it just contains all the DSS related patches. I don't see any other related branches. Tomi signature.asc Description: OpenPGP digital signature
Re: Help running latest linux-omap kernel on Nokia N810
Hi, On Thu, Feb 27, 2014 at 08:19:06AM +, Leigh Brown wrote: Did that driver work on the N810 at that point? If I look at the kernel tree at that point in time would all the components be there? It would make it easier if I had a starting point as I don't have any documentation so reading the old source code is the only way I can figure out how things work(ed). OpenWRT has patches to make the old blizzard driver work: http://git.openwrt.org/?p=openwrt.git;a=tree;f=target/linux/omap24xx/patches-3.3;h=c0cece34bf0a5f37496015c8e76c7eae636efe06;hb=HEAD See 310-n810-lcd.patch, and also you will need at least 312-no-hwmod-reset.patch, otherwise the HW won't respond at all. There is no known kernel tree with new (now deleted) panel-n8x0 that would work on N8x0. So probably the easiest route would be to take the old blizzard driver, forward port it to current kernel (the old omapfb is still supported) together with OpenWRT patches. This would probably get a working display with minor effort. Then start rewriting that code for the new framework and DT etc. A. -- 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: Help running latest linux-omap kernel on Nokia N810
On 27/02/14 21:38, Aaro Koskinen wrote: Hi, On Thu, Feb 27, 2014 at 08:19:06AM +, Leigh Brown wrote: Did that driver work on the N810 at that point? If I look at the kernel tree at that point in time would all the components be there? It would make it easier if I had a starting point as I don't have any documentation so reading the old source code is the only way I can figure out how things work(ed). OpenWRT has patches to make the old blizzard driver work: http://git.openwrt.org/?p=openwrt.git;a=tree;f=target/linux/omap24xx/patches-3.3;h=c0cece34bf0a5f37496015c8e76c7eae636efe06;hb=HEAD See 310-n810-lcd.patch, and also you will need at least 312-no-hwmod-reset.patch, otherwise the HW won't respond at all. There is no known kernel tree with new (now deleted) panel-n8x0 that would work on N8x0. So probably the easiest route would be to take the old blizzard driver, forward port it to current kernel (the old omapfb is still supported) The old omapfb driver (drivers/video/omap/) only supports omap1. The unused omap2 code was removed. What I would probably do is get an old kernel that has working display. Then add some hacks to get register dumps for RFBI, blizzard and the panel, and see what gpios, regulators, etc are turned on and connected to blizzard or the panel. And then just start from scratch with the latest kernel, copy-pasting parts of the driver. That's more or less what I did when I made the N800 display work with the new omapfb and omapdss (drivers/video/omap2/). Tomi signature.asc Description: OpenPGP digital signature
Re: Help running latest linux-omap kernel on Nokia N810
Hi, On Wed, Feb 26, 2014 at 06:24:36PM +, Leigh Brown wrote: I have built the latest linux-omap git tree for my N810 but when I boot it I get a black screen with the backlight on. Does anyone have a working .config that they could share with me? During my investigations I have discovered that the kernel configuration has changed enormously in the last couple of years. I was worried that the N810 was no longer supported at allm especially when I saw that a few of the old drivers (blizzard) had been removed. I was pleasantly surprised when I discovered that a lot of the old drivers had been replaced by new ones. I will document the latest state of play with the N810 once I have got things going. All I really want is a text console with working keyboard and wifi, initially. Any help will be gratefully received. I can't help much, because I do not own any N8x0 device, but you should probably visit [0] (and update it once you get stuff working :)) The omap platform is currently moving over to Device Tree [1] based booting, so you come at the right time to test DT based booting on your N810. Building a DT kernel for your N810 works like this: enable the following config entries: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y CONFIG_PINCTRL=y CONFIG_PINCTRL_SINGLE=y and build zImage like this: $ export ARCH=arm $ export CROSS_COMPILE=arm-linux-gnueabi- $ make zImage $ make omap2420-n810.dtb $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb zImage Be aware, that the DTS file seems to lack display keyboard support at the moment, so you may want to start building a serial adapter first. See [2] for details on this. This may seem like lots of work, but it really makes things much easier. [0] http://elinux.org/N800 [1] http://devicetree.org/ [2] http://bues.ch/cms/hacking/n810-serial.html -- Sebastian signature.asc Description: Digital signature
Re: Help running latest linux-omap kernel on Nokia N810
* Sebastian Reichel s...@ring0.de [140226 10:56]: Hi, On Wed, Feb 26, 2014 at 06:24:36PM +, Leigh Brown wrote: I have built the latest linux-omap git tree for my N810 but when I boot it I get a black screen with the backlight on. Does anyone have a working .config that they could share with me? Attached is what I've been using for my boot testing. If it does not fit into the memory, you need to cut down on the options. During my investigations I have discovered that the kernel configuration has changed enormously in the last couple of years. I was worried that the N810 was no longer supported at allm especially when I saw that a few of the old drivers (blizzard) had been removed. I was pleasantly surprised when I discovered that a lot of the old drivers had been replaced by new ones. I will document the latest state of play with the N810 once I have got things going. All I really want is a text console with working keyboard and wifi, initially. Any help will be gratefully received. I can't help much, because I do not own any N8x0 device, but you should probably visit [0] (and update it once you get stuff working :)) The omap platform is currently moving over to Device Tree [1] based booting, so you come at the right time to test DT based booting on your N810. Building a DT kernel for your N810 works like this: enable the following config entries: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y CONFIG_PINCTRL=y CONFIG_PINCTRL_SINGLE=y and build zImage like this: $ export ARCH=arm $ export CROSS_COMPILE=arm-linux-gnueabi- $ make zImage $ make omap2420-n810.dtb $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb zImage Be aware, that the DTS file seems to lack display keyboard support at the moment, so you may want to start building a serial adapter first. See [2] for details on this. This may seem like lots of work, but it really makes things much easier. Yeah the above should pretty much do it for booting it :) Regards, Tony [0] http://elinux.org/N800 [1] http://devicetree.org/ [2] http://bues.ch/cms/hacking/n810-serial.html CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y CONFIG_KPROBES=y CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y # CONFIG_EFI_PARTITION is not set CONFIG_ARCH_MULTI_V6=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARCH_OMAP2=y # CONFIG_SOC_OMAP2430 is not set CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y CONFIG_ARM_ERRATA_720789=y CONFIG_ARM_ERRATA_754322=y CONFIG_ARM_ERRATA_775420=y # CONFIG_COMPACTION is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk ignore_loglevel CONFIG_KEXEC=y CONFIG_FPE_NWFPE=y CONFIG_BINFMT_MISC=y CONFIG_PM_DEBUG=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_INET_LRO is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y CONFIG_BT=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_CFG80211=m CONFIG_CFG80211_WEXT=y CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_OMAP_INTERCONNECT=y CONFIG_CONNECTOR=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_OOPS=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_OMAP2=y CONFIG_MTD_ONENAND=y CONFIG_MTD_ONENAND_VERIFY_WRITE=y CONFIG_MTD_ONENAND_OMAP2=y CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_MD=y CONFIG_NETDEVICES=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y CONFIG_SMC91X=y CONFIG_SMSC911X=y CONFIG_SMSC_PHY=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m CONFIG_LIBERTAS_DEBUG=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_TWL4030=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_RETU_PWRBUTTON=y CONFIG_INPUT_TWL4030_PWRBUTTON=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32
Re: Help running latest linux-omap kernel on Nokia N810
Hi, On Wed, Feb 26, 2014 at 07:53:32PM +0100, Sebastian Reichel wrote: On Wed, Feb 26, 2014 at 06:24:36PM +, Leigh Brown wrote: Does anyone have a working .config that they could share with me? Yes. During my investigations I have discovered that the kernel configuration has changed enormously in the last couple of years. I was worried that the N810 was no longer supported at allm especially when I saw that a few of the old drivers (blizzard) had been removed. I was pleasantly surprised when I discovered that a lot of the old drivers had been replaced by new ones. I will document the latest state of play with the N810 once I have got things going. All I really want is a text console with working keyboard and wifi, initially. First the bad news: display support is not in the mainline kernel. Also since linux-omap tree follows the mainline, it's not there either anymore. Tomi removed the n8x0 panel driver some time ago (I don't know why), but even then it wasn't working as the platform data failed to set up some needed things properly. I was trying to get it working at but failed before the driver got removed. Anyway, this is still on my backlog and at some point I will try to reintroduce the display support. Meanwhile, the OMAP2 has been converted to DT so this is not going to be trivial so any help in this effort is appreciated. (Read: please send patches :)) Good news: it's still possible to run current mainline Linux on N8x0. But only basic functionality is there. You can interact with the device at least over UART and USB (e.g. ssh connection with USB networking). MMC and flash should work too. I haven't yet tested the WIFI. I'm booting test kernels with 0x - the N8x0 has 2MB limitation for the kernel, so I'm using kexec (tiny kernel) to boot a full-featured kernel from MMC. My kernel configs for 3.13 are available here: http://www.iki.fi/aaro/comp/linux/v3.13/arm-testresults.html. Building a serial adapter to develop Linux on N8x0 isn't strictly necessary as long as you get the USB is working. However it will ease things alot. 770/N800 are more friendly in this regard, as you can access the serial pins without removing the battery. A. -- 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: Help running latest linux-omap kernel on Nokia N810
On 26/02/14 23:29, Aaro Koskinen wrote: First the bad news: display support is not in the mainline kernel. Also since linux-omap tree follows the mainline, it's not there either anymore. Tomi removed the n8x0 panel driver some time ago (I don't know why), but even then it wasn't working as the platform data failed to set up some It would've been a big effort to keep the panel driver compiling, as we moved to a new display driver architecture. And, as it wasn't working anyway, I deemed it simpler to just remove it. I have no objections to add it back, but it needs to be split into two separate drivers, blizzard encoder driver and the panel driver. The RFBI driver also probably needs some love. And, of course, DT support for all those. In theory, RFBI is relatively simple. If I recall right, the panel is also quite simple, although it still needs to be controlled via SPI. Blizzard was a bit more complex one, but perhaps most of its features can be just left out. But getting all those three working fine without being able to make any measurements between the components, well, one might needs some luck there =). I do have N800 and N810 (no serial mods), so I might be able to give some help there at some point, if I'm able to boot the board with usb gadget ethernet (which hasn't been working for me for omap3 for some time). Tomi signature.asc Description: OpenPGP digital signature
Problems with double, qreal and float porting an application - Help please!
System is an ODROID-X.
root@odroid:/1/cuSDR32# uname -a
Linux odroid 3.8.13.14 #1 SMP PREEMPT Sat Dec 21 22:14:31 UTC 2013
armv7l armv7l armv7l GNU/Linux
root@odroid:/1/cuSDR32# cat /etc/os-release
NAME=Ubuntu
VERSION=13.10, Saucy Salamander
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME=Ubuntu 13.10
VERSION_ID=13.10
HOME_URL=http://www.ubuntu.com/;
SUPPORT_URL=http://help.ubuntu.com/;
BUG_REPORT_URL=http://bugs.launchpad.net/ubuntu/;
The failures and the offending lines below.
---
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_MULTIMEDIA_LIB
-DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtMultimedia
-I/usr/include/qt4 -I/usr/include/QtMultimediaKit
-I/usr/include/QtMobility -I. -Isrc -Isrc/AudioEngine -Isrc/CL
-Isrc/DataEngine -Isrc/GL -Isrc/QtDSP -Isrc/Util -I/usr/X11R6/include
-Ibld/moc -o bld/o/qtdsp_wpagc.o src/QtDSP/qtdsp_wpagc.cpp
src/QtDSP/qtdsp_wpagc.cpp: In member function ‘void
QWPAGC::ProcessAGC(CPX, CPX, int)’:
src/QtDSP/qtdsp_wpagc.cpp:290:88: error: no matching function for call
to ‘qMin(double, float)’
mult = (m_out_target - m_slope_constant * qMin(0.0, log10
(m_inv_max_input * m_volts))) / m_volts;
^
src/QtDSP/qtdsp_wpagc.cpp:290:88: note: candidate is:
In file included from /usr/include/qt4/QtCore/qiterator.h:45:0,
from /usr/include/qt4/QtCore/qvector.h:45,
from /usr/include/qt4/QtCore/QVector:1,
from src/QtDSP/qtdsp_qComplex.h:34,
from src/QtDSP/qtdsp_wpagc.h:36,
from src/QtDSP/qtdsp_wpagc.cpp:34:
/usr/include/qt4/QtCore/qglobal.h:1213:34: note: templateclass T const
T qMin(const T, const T)
Q_DECL_CONSTEXPR inline const T qMin(const T a, const T b) { return
(a b) ? a : b; }
^
/usr/include/qt4/QtCore/qglobal.h:1213:34: note: template argument
deduction/substitution failed:
src/QtDSP/qtdsp_wpagc.cpp:290:88: note: deduced conflicting types for
parameter ‘const T’ (‘double’ and ‘float’)
mult = (m_out_target - m_slope_constant * qMin(0.0, log10
(m_inv_max_input * m_volts))) / m_volts;
^
src/QtDSP/qtdsp_wpagc.cpp: In member function ‘void
QWPAGC::setHangLevelDb(qreal)’:
src/QtDSP/qtdsp_wpagc.cpp:588:78: error: no matching function for call
to ‘qMax(double, qreal)’
qreal tmp = qMax(1.0e-8, (convert - m_minVolts) / (m_maxInput -
m_minVolts));
^
src/QtDSP/qtdsp_wpagc.cpp:588:78: note: candidate is:
In file included from /usr/include/qt4/QtCore/qiterator.h:45:0,
from /usr/include/qt4/QtCore/qvector.h:45,
from /usr/include/qt4/QtCore/QVector:1,
from src/QtDSP/qtdsp_qComplex.h:34,
from src/QtDSP/qtdsp_wpagc.h:36,
from src/QtDSP/qtdsp_wpagc.cpp:34:
/usr/include/qt4/QtCore/qglobal.h:1215:34: note: templateclass T const
T qMax(const T, const T)
Q_DECL_CONSTEXPR inline const T qMax(const T a, const T b) { return
(a b) ? b : a; }
^
/usr/include/qt4/QtCore/qglobal.h:1215:34: note: template argument
deduction/substitution failed:
src/QtDSP/qtdsp_wpagc.cpp:588:78: note: deduced conflicting types for
parameter ‘const T’ (‘double’ and ‘qreal {aka float}’)
qreal tmp = qMax(1.0e-8, (convert - m_minVolts) / (m_maxInput -
m_minVolts));
^
make: *** [bld/o/qtdsp_wpagc.o] Error 1
root@odroid:/1/cuSDR32#
svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR32/ for the
source.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
Hi Nishant,
I've configured the device tree as you told me. Now, my device tree code
is that:
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..5644260 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -41,6 +41,12 @@
0xb6 (PIN_OUTPUT | MUX_MODE3)/* gpio_110 */
;
};
+
+lsm6db0_pins: lsm6db0_pins {
+pinctrl-single,pins =
+0xfc (PIN_INPUT | MUX_MODE3) /* mcspi1_cs2.gpio_139 */
+;
+};
};
led_wkgpio_pins {
@@ -49,6 +55,22 @@
;
};
+i2c4 {
+pinctrl-names = default;
+pinctrl-0 = i2c4_pins;
+
+clock-frequency = 40;
+
+lsm6db0@03 {
+pinctrl-names = default;
+pinctrl-0 = lsm6db0_pins;
+compatible = st,lsm6db0;
+reg = 0x03;
+interrupts = 139 0x1;
+interrupt-parent = lsm6db0_pins;
+};
+};
+
leds {
pinctrl-0 =
led_gpio_pins
I've also read the documentation file
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
but I'm confused about the gpio muxed with mcspi1.
Do you think my patch is correct?
Thanks,
Denis
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
Maybe, this is more correctly but still doesn't work...
From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
From: Denis Ciocca denis.cio...@st.com
Date: Thu, 12 Dec 2013 14:52:39 +0100
Subject: [PATCH] device tree
---
arch/arm/boot/dts/omap4-panda-es.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..82c3eb7 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -41,6 +41,12 @@
0xb6 (PIN_OUTPUT | MUX_MODE3)/* gpio_110 */
;
};
+
+lsm6db0_pins: lsm6db0_pins {
+pinctrl-single,pins =
+0xf6 (PIN_INPUT | MUX_MODE3) /* mcspi1_simo.gpio_136 */
+;
+};
};
led_wkgpio_pins {
@@ -49,6 +55,22 @@
;
};
+i2c4 {
+pinctrl-names = default;
+pinctrl-0 = i2c4_pins;
+
+clock-frequency = 40;
+
+lsm6db0@03 {
+pinctrl-names = default;
+pinctrl-0 = lsm6db0_pins;
+compatible = st,lsm6db0;
+reg = 0x03;
+interrupts = mcspi1 136 IRQ_TYPE_LEVEL_HIGH;
+interrupt-parent = mcspi1;
+};
+};
+
leds {
pinctrl-0 =
led_gpio_pins
--
1.7.9.5
No one can help me?
Thanks,
Denis
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
On 12/12/2013 08:27 AM, Denis CIOCCA wrote:
Maybe, this is more correctly but still doesn't work...
From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
From: Denis Ciocca denis.cio...@st.com
Date: Thu, 12 Dec 2013 14:52:39 +0100
Subject: [PATCH] device tree
---
arch/arm/boot/dts/omap4-panda-es.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..82c3eb7 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -41,6 +41,12 @@
0xb6 (PIN_OUTPUT | MUX_MODE3)/* gpio_110 */
;
};
+
+lsm6db0_pins: lsm6db0_pins {
+pinctrl-single,pins =
+0xf6 (PIN_INPUT | MUX_MODE3) /* mcspi1_simo.gpio_136 */
+;
+};
};
led_wkgpio_pins {
@@ -49,6 +55,22 @@
;
};
+i2c4 {
+pinctrl-names = default;
+pinctrl-0 = i2c4_pins;
+
+clock-frequency = 40;
+
+lsm6db0@03 {
+pinctrl-names = default;
+pinctrl-0 = lsm6db0_pins;
+compatible = st,lsm6db0;
+reg = 0x03;
+interrupts = mcspi1 136 IRQ_TYPE_LEVEL_HIGH;
+interrupt-parent = mcspi1;
why is mcspi1 your interrupt parent when you did a padconf for GPIO?
you want GPIO136, so you need the right gpio block as the interrupt
parent and map interrupts in the correct map.
see [1] for an example (omap2).
+};
+};
+
leds {
pinctrl-0 =
led_gpio_pins
[1]
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tree/arch/arm/boot/dts/omap2430-sdp.dts?id=omap-for-v3.14/omap3-board-removal-wl1251#n42
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
why is mcspi1 your interrupt parent when you did a padconf for GPIO? you want GPIO136, so you need the right gpio block as the interrupt parent and map interrupts in the correct map. see [1] for an example (omap2). Oh my god! Now I've understand how device tree works...I'm sorry Nishanth but the dt it's new for me...ok I'm using gpio5 and now it works! +interrupt-parent = gpio5; + interrupts = 8 IRQ_TYPE_LEVEL_HIGH; /* gpio line 136 */ Thank you very much for your patience...;) BR, Denis-- 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: need help to configure IRQ on gpio 139 pandaboard using device tree
On 12/12/2013 09:05 AM, Denis CIOCCA wrote: why is mcspi1 your interrupt parent when you did a padconf for GPIO? you want GPIO136, so you need the right gpio block as the interrupt parent and map interrupts in the correct map. see [1] for an example (omap2). Oh my god! Now I've understand how device tree works...I'm sorry Nishanth but the dt it's new for me...ok I'm using gpio5 and now it works! +interrupt-parent = gpio5; + interrupts = 8 IRQ_TYPE_LEVEL_HIGH; /* gpio line 136 */ Thank you very much for your patience...;) glad to hear it worked, yeah, device tree is a little different, but logical in it's own way. 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
need help to configure IRQ on gpio 139 pandaboard using device tree
Hi everybody,
I'm trying to configure an IRQ on pandaboard using device tree but I'm
not able to understand how I can do it.
I want to configure the the gpio_139 pin and without device tree my
command was:
OMAP4_MUX(MCSPI1_SIMO, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
I need to associate it to a i2c device, declared in this way:
i2c4 {
pinctrl-names = default;
pinctrl-0 = i2c4_pins;
clock-frequency = 40;
lsm303d@03 {
compatible = st,lsm303d;
reg = 0x03;
};
};
and it works, but I don't know how I can set the interrupt using:
interrupts = GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH; /* example */
Thanks,
Denis--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
On Wed, Dec 11, 2013 at 8:28 AM, Denis CIOCCA denis.cio...@st.com wrote:
Hi everybody,
I'm trying to configure an IRQ on pandaboard using device tree but I'm
not able to understand how I can do it.
I want to configure the the gpio_139 pin and without device tree my
command was:
OMAP4_MUX(MCSPI1_SIMO, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
I need to associate it to a i2c device, declared in this way:
here is how you'd figure it out in dt world ;) - it might be a little
simpler or harder depending on which end of the development world one
is from... (gmail might be screwing up my formatting a little.. so
apologies before hand.
http://pastebin.mozilla.org/3755622 is a copy if you need one.. anyways,
step 1: from trm, you get to know that the pin is part of core
SYSCTRL_PADCONF_CORE as it states for register instance in the trm.
step 2: you compute the offset
step 3: you define the pinctrl dt node
step 4: you'd provide the device using it reference - rather trivial ;)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..8f8d36c 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -41,6 +41,25 @@
0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 */
;
};
+
+ lsm303d_pins: lsm303d_pins {
+ pinctrl-single,pins =
+ /*
+ * Example for 4460 device:
+ * from arch/arm/boot/dts/omap4.dtsi:
+ * omap4_pmx_core: reg = 0x4a100040
+ * the base address -- ^^
+ *
+ * Now, the offset is computed as following:
+ * Download TRM: http://www.ti.com/lit/ug/swpu235aa/swpu235aa.pdf
+ * Searching in TRM for MCSPI1_SIMO (page 4145), you see:
+ * 32 bit register 0x4a100134, it is on the higher 16 bits
+ * 0x4a100134(SOMI) + 2 (SIMO) = 0x4a100136
+ * offset hence is = 0x4a100136 - 0x4a100040 = 0xF6
+ */
+ 0xF6 (PIN_INPUT_PULLUP | MUX_MODE3) /* mcspi1_somi.gpio_139 */
+ ;
+ };
};
led_wkgpio_pins {
@@ -62,3 +81,16 @@
gpios = gpio1 8 GPIO_ACTIVE_HIGH;
};
};
+i2c4 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c4_pins;
+
+ clock-frequency = 40;
+
+ lsm303d@03 {
+ pinctrl-names = default;
+ pinctrl-0 = lsm303d_pins;
+ compatible = st,lsm303d;
+ reg = 0x03;
+ };
+};
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
Hi Nishant,
Thank you very much for your suggestions! Now I understand how it
works...(I hope) :D
BUT, now I've checked the client-irq in an i2c driver and the value is
still 0...
What I have to check?
Thanks,
Denis
On 12/11/2013 04:39 PM, menon.nisha...@gmail.com wrote:
On Wed, Dec 11, 2013 at 8:28 AM, Denis CIOCCA denis.cio...@st.com wrote:
Hi everybody,
I'm trying to configure an IRQ on pandaboard using device tree but I'm
not able to understand how I can do it.
I want to configure the the gpio_139 pin and without device tree my
command was:
OMAP4_MUX(MCSPI1_SIMO, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
I need to associate it to a i2c device, declared in this way:
here is how you'd figure it out in dt world ;) - it might be a little
simpler or harder depending on which end of the development world one
is from... (gmail might be screwing up my formatting a little.. so
apologies before hand.
http://pastebin.mozilla.org/3755622 is a copy if you need one.. anyways,
step 1: from trm, you get to know that the pin is part of core
SYSCTRL_PADCONF_CORE as it states for register instance in the trm.
step 2: you compute the offset
step 3: you define the pinctrl dt node
step 4: you'd provide the device using it reference - rather trivial ;)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..8f8d36c 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -41,6 +41,25 @@
0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 */
;
};
+
+ lsm303d_pins: lsm303d_pins {
+ pinctrl-single,pins =
+ /*
+ * Example for 4460 device:
+ * from arch/arm/boot/dts/omap4.dtsi:
+ * omap4_pmx_core: reg = 0x4a100040
+ * the base address -- ^^
+ *
+ * Now, the offset is computed as following:
+ * Download TRM: http://www.ti.com/lit/ug/swpu235aa/swpu235aa.pdf
+ * Searching in TRM for MCSPI1_SIMO (page 4145), you see:
+ * 32 bit register 0x4a100134, it is on the higher 16 bits
+ * 0x4a100134(SOMI) + 2 (SIMO) = 0x4a100136
+ * offset hence is = 0x4a100136 - 0x4a100040 = 0xF6
+ */
+ 0xF6 (PIN_INPUT_PULLUP | MUX_MODE3) /* mcspi1_somi.gpio_139 */
+ ;
+ };
};
led_wkgpio_pins {
@@ -62,3 +81,16 @@
gpios = gpio1 8 GPIO_ACTIVE_HIGH;
};
};
+i2c4 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c4_pins;
+
+ clock-frequency = 40;
+
+ lsm303d@03 {
+ pinctrl-names = default;
+ pinctrl-0 = lsm303d_pins;
+ compatible = st,lsm303d;
+ reg = 0x03;
+ };
+};
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
On 12/11/2013 10:25 AM, Denis CIOCCA wrote: BUT, now I've checked the client-irq in an i2c driver and the value is still 0... I missed this: and it works, but I don't know how I can set the interrupt using: interrupts = GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH; /* example */ snip What I have to check? since your interrupt is an GPIO, as an example (probably wont match your case): interrupt-parent = gpio4; /* '4' is the GPIO BANK */ interrupts = 11 0; /* '11' maps to the gpio number, '0' (bits - interrupt-type */ [...] see Documentation/devicetree/bindings/interrupt-controller/interrupts.txt (hint: b) two cells) On 12/11/2013 04:39 PM, menon.nisha...@gmail.com wrote: For a future note, please avoid top-posting in mailing lists :) -- 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: Help needed to force USB host mode on AM335x CPU
Hi,
On Fri, Nov 22, 2013 at 02:28:50PM +, Mark Jackson wrote:
We have a custom AM335x board where the USB0_ID pin has been left floating.
By default, this puts the USB controller into peripheral mode, but we need
to force it into host mode.
This can be achieved in s/w by setting some bits in the relevant USB mode
register (see TRM 16.5.2.35).
This mode register's offset is already defined in musb_dsps.c
static const struct dsps_musb_wrapper am33xx_driver_data = {
...
.mode = 0xe8,
...
};
I can manually set this register to the correct value in musb_host.c and
the USB all seems to work as expected.
int musb_host_setup(struct musb *musb, int power_budget)
{
int ret;
struct usb_hcd *hcd = musb-hcd;
/* Force HOST mode */
unsigned long __iomem *p;
p = ioremap(0x474010e8, 4);
*p = 0x80;/* IDDIG = 0, IDDIG_MUX = 1 */
MUSB_HST_MODE(musb);
...
};
Ideally I'd like to add an entry in my dts file to flag for this force mode
to be setup, such as:-
usb@47401000 {
status = okay;
dr_mode = host;
ti,force-host; /* force host mode */
};
Can anyone point me in the right direction as to where to put this extra code
?
I see there's a musb_am335x.c file, but that just seems to be a wrapper.
Any help would be greatly apperciated.
I just sent two patches to linux-usb and I suppose they can help. In
fact, I remember now that I have to fix commit log on one of them. I'll
do that now.
cheers
--
balbi
signature.asc
Description: Digital signature
Help needed to force USB host mode on AM335x CPU
We have a custom AM335x board where the USB0_ID pin has been left floating.
By default, this puts the USB controller into peripheral mode, but we need
to force it into host mode.
This can be achieved in s/w by setting some bits in the relevant USB mode
register (see TRM 16.5.2.35).
This mode register's offset is already defined in musb_dsps.c
static const struct dsps_musb_wrapper am33xx_driver_data = {
...
.mode = 0xe8,
...
};
I can manually set this register to the correct value in musb_host.c and
the USB all seems to work as expected.
int musb_host_setup(struct musb *musb, int power_budget)
{
int ret;
struct usb_hcd *hcd = musb-hcd;
/* Force HOST mode */
unsigned long __iomem *p;
p = ioremap(0x474010e8, 4);
*p = 0x80; /* IDDIG = 0, IDDIG_MUX = 1 */
MUSB_HST_MODE(musb);
...
};
Ideally I'd like to add an entry in my dts file to flag for this force mode
to be setup, such as:-
usb@47401000 {
status = okay;
dr_mode = host;
ti,force-host; /* force host mode */
};
Can anyone point me in the right direction as to where to put this extra code ?
I see there's a musb_am335x.c file, but that just seems to be a wrapper.
Any help would be greatly apperciated.
Regards
Mark J.
--
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] DMA: add help function to check whether dma controller registered
On 08/22/2013 07:17 PM, Richard Zhao wrote: On Fri, Aug 23, 2013 at 04:36:53AM +0800, Stephen Warren wrote: On 08/22/2013 12:43 AM, Richard Zhao wrote: DMA client device driver usually needs to know at probe time whether dma controller has been registered to deffer probe. So add a help function of_dma_check_controller. DMA request channel functions can also used to check it, but they are usually called at open() time. This new function is almost identical to the existing of_dma_request_slave_channel(). Surely the code should be shared? ofdma-of_dma_xlate(dma_spec, ofdma); The above is called holding of_dma_lock. If I want to abstract the common lines, there' two options. What is the problem with acquiring the lock? If request_slave_channel() needs to take the lock, then there must be a reason which presumably applies to the other path too. ... But that said, I don't see any need for a new function; why can't drivers simply call of_dma_request_slave_channel() at probe time; It'll mislead user. channel supposed to be request at open time. I don't agree. from what I can see, that function doesn't actually request the channel, but rather simply looks it up, just like this one. The only difference is that of_dma_xlate() is also called, but that's just doing some data transformation, not actually recording channel ownership. xlate function request the channel if things go well. Oh. xlate should not do that; that's a design flaw. xlate should do nothing more than translate the DT content to an internal channel ID. -- 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] DMA: add help function to check whether dma controller registered
DMA client device driver usually needs to know at probe time whether
dma controller has been registered to deffer probe. So add a help
function of_dma_check_controller.
DMA request channel functions can also used to check it, but they
are usually called at open() time.
Signed-off-by: Richard Zhao riz...@nvidia.com
---
drivers/dma/of-dma.c | 39 +++
include/linux/of_dma.h | 6 ++
2 files changed, 45 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 8cd5f3f..0063ddf 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -189,6 +189,45 @@ struct dma_chan *of_dma_request_slave_channel(struct
device_node *np,
}
/**
+ * of_dma_check_controller - Check whether dma controller registered
+ * @dev: pointer to client device structure
+ * @name: slave channel name
+ */
+int of_dma_check_controller(struct device *dev, const char *name)
+{
+ struct device_node *np = dev-of_node;
+ struct of_phandle_args dma_spec;
+ struct of_dma *ofdma = NULL;
+ int count, i, ret = 0;
+
+ if (!np || !name)
+ return -EINVAL;
+
+ count = of_property_count_strings(np, dma-names);
+ if (count 0) {
+ dev_err(dev, dma-names property missing or empty\n);
+ return -EINVAL;
+ }
+
+ for (i = 0; i count; i++) {
+ ret = of_dma_match_channel(np, name, i, dma_spec);
+ if (ret)
+ continue;
+
+ mutex_lock(of_dma_lock);
+ ofdma = of_dma_find_controller(dma_spec);
+ mutex_unlock(of_dma_lock);
+ of_node_put(dma_spec.np);
+ if (!ofdma)
+ ret = -EPROBE_DEFER;
+ break;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_dma_check_controller);
+
+/**
* of_dma_simple_xlate - Simple DMA engine translation function
* @dma_spec: pointer to DMA specifier as found in the device tree
* @of_dma:pointer to DMA controller data
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..bc7195f 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -39,6 +39,7 @@ extern int of_dma_controller_register(struct device_node *np,
extern void of_dma_controller_free(struct device_node *np);
extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name);
+extern int of_dma_check_controller(struct device *dev, const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
#else
@@ -60,6 +61,11 @@ static inline struct dma_chan
*of_dma_request_slave_channel(struct device_node *
return NULL;
}
+static inline int of_dma_check_controller(struct device *dev, const char *name)
+{
+ return 0;
+}
+
static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args
*dma_spec,
struct of_dma *ofdma)
{
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] DMA: add help function to check whether dma controller registered
On 08/22/2013 12:43 AM, Richard Zhao wrote: DMA client device driver usually needs to know at probe time whether dma controller has been registered to deffer probe. So add a help function of_dma_check_controller. DMA request channel functions can also used to check it, but they are usually called at open() time. This new function is almost identical to the existing of_dma_request_slave_channel(). Surely the code should be shared? But that said, I don't see any need for a new function; why can't drivers simply call of_dma_request_slave_channel() at probe time; from what I can see, that function doesn't actually request the channel, but rather simply looks it up, just like this one. The only difference is that of_dma_xlate() is also called, but that's just doing some data transformation, not actually recording channel ownership. -- 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] DMA: add help function to check whether dma controller registered
On Fri, Aug 23, 2013 at 04:36:53AM +0800, Stephen Warren wrote:
On 08/22/2013 12:43 AM, Richard Zhao wrote:
DMA client device driver usually needs to know at probe time whether
dma controller has been registered to deffer probe. So add a help
function of_dma_check_controller.
DMA request channel functions can also used to check it, but they
are usually called at open() time.
This new function is almost identical to the existing
of_dma_request_slave_channel(). Surely the code should be shared?
ofdma-of_dma_xlate(dma_spec, ofdma);
The above is called holding of_dma_lock. If I want to abstract the
common lines, there' two options.
Option 1:
static struct of_dma* of_dma_check_controller_locked(np, name)
{
parameter check
get dma-names count and check return value
for loop to get of_dma
return PTR_ERR(err) or of_dma
}
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name)
{
chan = null;
mutex_lock(of_dma_lock);
of_dma = of_dma_check_controller_locked(np, name)
if(!IS_ERR(of_dma))
chan = ofdma-of_dma_xlate(dma_spec, ofdma);
mutex_unlock(of_dma_lock);
return chan;
}
int of_dma_check_controller(struct device *dev, const char *name)
{
mutex_lock(of_dma_lock);
ofdma = of_dma_check_controller_locked(dev-of_node, name);
mutex_unlock(of_dma_lock);
if (IS_ERR(ofdma))
return ERR_PTR(ofdma);
else
return 0;
}
Option 2:
static struct of_dma* of_dma_check_controller_getlock(np, name)
{
parameter check
get dma-names count and check return value
for loop to get of_dma, get lock at old place
if failed, unlock.
return PTR_ERR(err) or of_dma
}
struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name)
{
} of_dma = of_dma_check_controller_getlock(np, name)
if(!IS_ERR(of_dma)) {
chan = ofdma-of_dma_xlate(dma_spec, ofdma);
unlock;
}
return chan;
}
int of_dma_check_controller(struct device *dev, const char *name)
ofdma = of_dma_check_controller_locked(dev-of_node, name);
if (IS_ERR(ofdma)) {
return ERR_PTR(ofdma);
} else {
unlock;
return 0;
}
}
But that said, I don't see any need for a new function; why can't
drivers simply call of_dma_request_slave_channel() at probe time;
It'll mislead user. channel supposed to be request at open time.
from
what I can see, that function doesn't actually request the channel, but
rather simply looks it up, just like this one. The only difference is
that of_dma_xlate() is also called, but that's just doing some data
transformation, not actually recording channel ownership.
xlate function request the channel if things go well.
Thanks
Richard
--
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: Need help for DT GPIO probing
On Sunday 21 July 2013 07:10 AM, Linus Walleij wrote: On Sun, Jul 21, 2013 at 6:54 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Linus, are you still planing to send this patches as fixes for the v3.11 -rc cycle or did you decide to wait for v3.12? It will go into the v3.11 RC:s. Thanks Linus. IIRC, off-list I pointed out the same patch-set to Soumya. Regards, Santosh -- 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: Need help for DT GPIO probing
On Sun, Jul 21, 2013 at 6:54 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Linus, are you still planing to send this patches as fixes for the v3.11 -rc cycle or did you decide to wait for v3.12? It will go into the v3.11 RC:s. I've just been slow due to the current heatwave over northern Europe... Yours, Linus Walleij -- 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: Need help for DT GPIO probing
On Sunday, July 21, 2013, Linus Walleij wrote: On Sun, Jul 21, 2013 at 6:54 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Linus, are you still planing to send this patches as fixes for the v3.11 -rc cycle or did you decide to wait for v3.12? It will go into the v3.11 RC:s. Great, thanks a lot for your help! I've just been slow due to the current heatwave over northern Europe... Haha, yes weather has been even worst here in southern Europe Yours, Linus Walleij Best regards, Javier -- 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: Need help for DT GPIO probing
On Fri, Jul 12, 2013 at 4:05 PM, Soumya Sutar soumyasu...@gmail.com wrote: Hi Linus, I am facing DT GPIO probing problem same as below link. http://us.generation-nt.com/answer/gpio-crashed-when-not-using-help-208346861.html Could you know any patch is available for this issues or still we need to use gpio_request() in driver. Please ask questions like this on the mailing lists and include the OMAP GPIO maintainers (Santosh Kevin). And the answer is yes, all GPIO lines you are using need to be requested by the driver. Yours, Linus Walleij -- 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: Need help for DT GPIO probing
Hi Soumya On Saturday, July 20, 2013, Linus Walleij wrote: On Fri, Jul 12, 2013 at 4:05 PM, Soumya Sutar soumyasu...@gmail.com wrote: Hi Linus, I am facing DT GPIO probing problem same as below link. http://us.generation-nt.com/answer/gpio-crashed-when-not-using-help-208346861.html Could you know any patch is available for this issues or still we need to use gpio_request() in driver. Yes, Linus W has already queued some patches for gpio-omap on the for-next branch of his linux-gpio tree [1] that solves this issue. Take a look to commit b4419e1a (gpio/omap: auto request GPIO as input if used as IRQ via DT) although this patch depends on others so you should merge the whole branch to make it work. Linus, are you still planing to send this patches as fixes for the v3.11 -rc cycle or did you decide to wait for v3.12? Please ask questions like this on the mailing lists and include the OMAP GPIO maintainers (Santosh Kevin). And the answer is yes, all GPIO lines you are using need to be requested by the driver. Yours, Linus Walleij -- Thanks a lot and best regards, Javier [1]: https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/log/?h=for-next -- 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, RFC 4/8] ARM: am33xx: ll debug config help
On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote: Selecting DEBUG_AM33XXUART1 routes low level debug messages to first UART instance of AM335x based SoC's. This selection is valid for upcoming AM43 based SoC's too. Make this information available upon configuring. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/Kconfig.debug | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index aca..b717b78 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -542,6 +542,9 @@ choice config DEBUG_AM33XXUART1 bool AM33XX UART1 + help + Route low level debug messages to first uart instance + for boards based on am335 and am43 family of SoC's config DEBUG_ZOOM_UART bool Zoom2/3 UART With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S to get the earlyprintk working ? Regards, Santosh -- 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, RFC 4/8] ARM: am33xx: ll debug config help
Hi Santosh,
On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote:
With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S
to get the earlyprintk working ?
No, on linux-next, ll debug works properly.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH, RFC 4/8] ARM: am33xx: ll debug config help
On Tuesday 19 February 2013 04:00 PM, Mohammed, Afzal wrote: Hi Santosh, On Tue, Feb 19, 2013 at 15:55:59, Shilimkar, Santosh wrote: With DT, IIRC DEBUGLL is broken. So did you hack debug-macro.S to get the earlyprintk working ? No, on linux-next, ll debug works properly. Indeed. Tony fixed that now. Some how I missed this patch on the list. Regards, Santosh -- 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, RFC 4/8] ARM: am33xx: ll debug config help
Selecting DEBUG_AM33XXUART1 routes low level debug messages to first UART instance of AM335x based SoC's. This selection is valid for upcoming AM43 based SoC's too. Make this information available upon configuring. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/Kconfig.debug | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index aca..b717b78 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -542,6 +542,9 @@ choice config DEBUG_AM33XXUART1 bool AM33XX UART1 + help + Route low level debug messages to first uart instance + for boards based on am335 and am43 family of SoC's config DEBUG_ZOOM_UART bool Zoom2/3 UART -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/8] ARM: am33xx: ll debug config help
Selecting DEBUG_AM33XXUART1 routes low level debug messages to first UART instance of AM335x based SoC's. This selection is valid for upcoming AM43 based SoC's too. Make this information available upon configuring. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/Kconfig.debug | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index aca..b717b78 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -542,6 +542,9 @@ choice config DEBUG_AM33XXUART1 bool AM33XX UART1 + help + Route low level debug messages to first uart instance + for boards based on am335 and am43 family of SoC's config DEBUG_ZOOM_UART bool Zoom2/3 UART -- 1.7.12 -- 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: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 17 Jan 2013 11:22:55 +1100 NeilBrown ne...@suse.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 12:19, NeilBrown wrote: On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 09:26, NeilBrown wrote: On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il wrote: On 01/09/13 14:08, Michael Trimarchi wrote: Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. I've tried various change w.r.t the resetting and I cannot fault it. Resetting or not resetting neither causes a problem while the USB is otherwise working, not fixed the USB while it is otherwise failing. So I don't think this is my problem - thanks. Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for this. I assume this means some patches on top of 3.6.1 ?? Care to share your code? Even horribly ugly hacks can be educational. We are not ready to share these patches (this will happen eventually after some work is finished), but I can explain what they do... We split the ehci_run function to separate the debugfs and sysfs stuff from other initializations, so we can run the new version without the debugfs and sysfs stuff multiple times. Then we implement the suspend/resume ehci callbacks: on suspend, assert phy reset, on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to EHCI_INSNREG04, and call the new ehci_run() function. That does the job for USB host to resume from off mode. Interesting thanks. That makes a certain amount of sense. However I tried compiling ehci-hcd as a module and unload/reloading it which should have a similar net effect to what you did, but it didn't make any difference - device disappears on resume. Yes it does for cm-t3730, in fact, that is what we have started from... I also tried restoring the correct value to EHCI_INSNREG04 and EHCI_INSNREG05_ULPI which are the only registers written by ehci-omap.c, and that didn't help either. The only thing I've found that works is keeping 'core' out of off-mode. Ah, one more thing, we ensure that phy is completely powered off through the TPS power scripts, otherwise, it does not work... Ahhh that does make a difference. I turned off the 5V5 rail which powered the phy (and a few other things) and now the usb-attached modem appears after resume. Very interesting. I hadn't been doing
Re: Help wanted with USB and OMAP3 off_mode
On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros rog...@ti.com wrote: On 01/16/2013 12:27 PM, NeilBrown wrote: On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote: On 01/09/2013 12:29 AM, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). After a suspend/resume cycle with off_mode enabled the GSM module disappears. i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't exist. Without off mode, the modem always appears after resume. I discovered that the registers set by: drivers/mfd/omap-usb-host.c are not maintained across as suspend/resume so I added the following patch (which I can make a formal submission of if it looks right to others), but that didn't help (or didn't help enough). If I echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend thus keeping just the USBHOST power domain out of off_mode, the GSM module doesn't disappear. So it seems that some context in the usbhost domain is not being save and restored. This is as far as I can get. Can someone suggest where I should look to find out what is not being saved/restored properly, and how to go about saving and restoring? You need to ensure that USBHOST/TLL context is saved as per the Save and Restore sequence see section USBHOST/USBTLL Save-and-Restore Management in the OMAP Technical Reference Manual. The basic idea there is that software does the context saving into SAR RAM before entering OFF mode and hardware automatically restores the context after coming out of OFF mode. Is it? The way I read the doco, the hardware both saves to SAR RAM, and restores from SAR RAM. Section 22.2.4.1.6 Save and Restore of my copy of the TRM says: The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host controller (after all USB activity has been suspended) before switching off (=save), save it to an external always-on memory, and reinject it later after the module has been switched on again and reset (=restore) seamlessly for the USB. Part of that context is composed of the register fields described in the current chapter. The rest of the context is composed of the buried flip-flops and memories (not accessible by software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits. which strongly suggests that it is all handled by hardware. Of course there are other registers that aren't covered by the SAR - we need to identify those and make sure they are saved and restored. I've found a few registers that aren't being restored, but restoring them hasn't made a visible difference yet. Yes, you are right. I mixed it up with OMAP4 behaviour, sorry. But still, software needs to ensure that the USBHOST and CORE power domain's SAVEANDRESTORE bit are set to ensure that SAR works. see section 3.5.4.6 USBHOST/USBTLL Save-and-Restore Management This seems to be done by the powerdomain code based on the PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST powerdomain with the following comment. Both USBHOST and USBTLL support a save-and-restore mechanism. When the device enters into off mode (that is, all power domains, except the WKUP power domain, are off), the user may want to save the USBHOST context and restore it when exiting off mode. The save-and-restore mechanism for the HS USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] SAVEANDRESTORE bit; for the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE bit. The save mechanism is initiated as the power domain transitions from active to off state (or to OSWR state for the USBTLL), whereas the restore mechanism is initiated as the power domain transitions from off to active power state. Can you try with the flag enabled? If I keep CORE and USBHOST out of off-mode (by writing to the relevant 'suspend' files in /sys/kernel/debug/pm-debug) then it all works. If I set this flag, then I can allow USBHOST to enter off-mode as long as I keep CORE in retention or better. If I let CORE and USBHOST go to off-mode and don't have the flag set, then I can resume from suspend, but the usb modem has disappeared. If I let CORE and USBHOST go to off-mode and DO have the flag set, then I cannot even resume from suspend sometimes. I hate those sometimess! If I remove the battery (with no other power source present) and re-insert it, and let the phone boot up to stable state and then enter suspend, I cannot resume from suspend. (I tried setting no_console_suspend to see if anything was happening - but that keeps
Re: Help wanted with USB and OMAP3 off_mode
On 01/17/2013 01:01 PM, NeilBrown wrote: On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros rog...@ti.com wrote: On 01/16/2013 12:27 PM, NeilBrown wrote: On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote: On 01/09/2013 12:29 AM, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). After a suspend/resume cycle with off_mode enabled the GSM module disappears. i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't exist. Without off mode, the modem always appears after resume. I discovered that the registers set by: drivers/mfd/omap-usb-host.c are not maintained across as suspend/resume so I added the following patch (which I can make a formal submission of if it looks right to others), but that didn't help (or didn't help enough). If I echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend thus keeping just the USBHOST power domain out of off_mode, the GSM module doesn't disappear. So it seems that some context in the usbhost domain is not being save and restored. This is as far as I can get. Can someone suggest where I should look to find out what is not being saved/restored properly, and how to go about saving and restoring? You need to ensure that USBHOST/TLL context is saved as per the Save and Restore sequence see section USBHOST/USBTLL Save-and-Restore Management in the OMAP Technical Reference Manual. The basic idea there is that software does the context saving into SAR RAM before entering OFF mode and hardware automatically restores the context after coming out of OFF mode. Is it? The way I read the doco, the hardware both saves to SAR RAM, and restores from SAR RAM. Section 22.2.4.1.6 Save and Restore of my copy of the TRM says: The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host controller (after all USB activity has been suspended) before switching off (=save), save it to an external always-on memory, and reinject it later after the module has been switched on again and reset (=restore) seamlessly for the USB. Part of that context is composed of the register fields described in the current chapter. The rest of the context is composed of the buried flip-flops and memories (not accessible by software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits. which strongly suggests that it is all handled by hardware. Of course there are other registers that aren't covered by the SAR - we need to identify those and make sure they are saved and restored. I've found a few registers that aren't being restored, but restoring them hasn't made a visible difference yet. Yes, you are right. I mixed it up with OMAP4 behaviour, sorry. But still, software needs to ensure that the USBHOST and CORE power domain's SAVEANDRESTORE bit are set to ensure that SAR works. see section 3.5.4.6 USBHOST/USBTLL Save-and-Restore Management This seems to be done by the powerdomain code based on the PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST powerdomain with the following comment. Both USBHOST and USBTLL support a save-and-restore mechanism. When the device enters into off mode (that is, all power domains, except the WKUP power domain, are off), the user may want to save the USBHOST context and restore it when exiting off mode. The save-and-restore mechanism for the HS USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] SAVEANDRESTORE bit; for the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE bit. The save mechanism is initiated as the power domain transitions from active to off state (or to OSWR state for the USBTLL), whereas the restore mechanism is initiated as the power domain transitions from off to active power state. Can you try with the flag enabled? If I keep CORE and USBHOST out of off-mode (by writing to the relevant 'suspend' files in /sys/kernel/debug/pm-debug) then it all works. If I set this flag, then I can allow USBHOST to enter off-mode as long as I keep CORE in retention or better. If I let CORE and USBHOST go to off-mode and don't have the flag set, then I can resume from suspend, but the usb modem has disappeared. If I let CORE and USBHOST go to off-mode and DO have the flag set, then I cannot even resume from suspend sometimes. It looks like the problem creeps in when the OMAP device hits OFF. i.e. CORE is allowed to go OFF. I hate those sometimess! If I remove the battery (with no other power source present) and re-insert it, and let the phone boot up to stable state and then enter suspend, I cannot resume from suspend. (I tried setting
Re: Help wanted with USB and OMAP3 off_mode
On Thu, 17 Jan 2013 13:29:07 +0200 Roger Quadros rog...@ti.com wrote: On 01/17/2013 01:01 PM, NeilBrown wrote: On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros rog...@ti.com wrote: On 01/16/2013 12:27 PM, NeilBrown wrote: On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote: On 01/09/2013 12:29 AM, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). After a suspend/resume cycle with off_mode enabled the GSM module disappears. i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't exist. Without off mode, the modem always appears after resume. I discovered that the registers set by: drivers/mfd/omap-usb-host.c are not maintained across as suspend/resume so I added the following patch (which I can make a formal submission of if it looks right to others), but that didn't help (or didn't help enough). If I echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend thus keeping just the USBHOST power domain out of off_mode, the GSM module doesn't disappear. So it seems that some context in the usbhost domain is not being save and restored. This is as far as I can get. Can someone suggest where I should look to find out what is not being saved/restored properly, and how to go about saving and restoring? You need to ensure that USBHOST/TLL context is saved as per the Save and Restore sequence see section USBHOST/USBTLL Save-and-Restore Management in the OMAP Technical Reference Manual. The basic idea there is that software does the context saving into SAR RAM before entering OFF mode and hardware automatically restores the context after coming out of OFF mode. Is it? The way I read the doco, the hardware both saves to SAR RAM, and restores from SAR RAM. Section 22.2.4.1.6 Save and Restore of my copy of the TRM says: The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host controller (after all USB activity has been suspended) before switching off (=save), save it to an external always-on memory, and reinject it later after the module has been switched on again and reset (=restore) seamlessly for the USB. Part of that context is composed of the register fields described in the current chapter. The rest of the context is composed of the buried flip-flops and memories (not accessible by software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits. which strongly suggests that it is all handled by hardware. Of course there are other registers that aren't covered by the SAR - we need to identify those and make sure they are saved and restored. I've found a few registers that aren't being restored, but restoring them hasn't made a visible difference yet. Yes, you are right. I mixed it up with OMAP4 behaviour, sorry. But still, software needs to ensure that the USBHOST and CORE power domain's SAVEANDRESTORE bit are set to ensure that SAR works. see section 3.5.4.6 USBHOST/USBTLL Save-and-Restore Management This seems to be done by the powerdomain code based on the PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST powerdomain with the following comment. Both USBHOST and USBTLL support a save-and-restore mechanism. When the device enters into off mode (that is, all power domains, except the WKUP power domain, are off), the user may want to save the USBHOST context and restore it when exiting off mode. The save-and-restore mechanism for the HS USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] SAVEANDRESTORE bit; for the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE bit. The save mechanism is initiated as the power domain transitions from active to off state (or to OSWR state for the USBTLL), whereas the restore mechanism is initiated as the power domain transitions from off to active power state. Can you try with the flag enabled? If I keep CORE and USBHOST out of off-mode (by writing to the relevant 'suspend' files in /sys/kernel/debug/pm-debug) then it all works. If I set this flag, then I can allow USBHOST to enter off-mode as long as I keep CORE in retention or better. If I let CORE and USBHOST go to off-mode and don't have the flag set, then I can resume from suspend, but the usb modem has disappeared. If I let CORE and USBHOST go to off-mode and DO have the flag set, then I cannot even resume from suspend sometimes. It looks like the problem creeps in when the OMAP device hits OFF. i.e. CORE is allowed to go OFF. I hate those
Re: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 09:26, NeilBrown wrote: On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il wrote: On 01/09/13 14:08, Michael Trimarchi wrote: Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. I've tried various change w.r.t the resetting and I cannot fault it. Resetting or not resetting neither causes a problem while the USB is otherwise working, not fixed the USB while it is otherwise failing. So I don't think this is my problem - thanks. Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for this. I assume this means some patches on top of 3.6.1 ?? Care to share your code? Even horribly ugly hacks can be educational. We are not ready to share these patches (this will happen eventually after some work is finished), but I can explain what they do... We split the ehci_run function to separate the debugfs and sysfs stuff from other initializations, so we can run the new version without the debugfs and sysfs stuff multiple times. Then we implement the suspend/resume ehci callbacks: on suspend, assert phy reset, on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to EHCI_INSNREG04, and call the new ehci_run() function. That does the job for USB host to resume from off mode. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ9nKiAAoJEBDE8YO64Efa7U4QAKFXRyyNR5Q7jjwVG6UwITWq 6kJyNXJKQTqn6GLEV7xJmT4SZAtxq+dRDl/XE9dcXFK3RTebttXxyVz1X0vXZQud h6QLenH8jHczNubfn6CTLI38PKprl1F2zpZtjKpHfNmD5cLWzJ1EIoTH19ENsJ4v zV3KI3RgiFuq02vxOULtp9gP/x0WZSHwBEGm/ToqqsEaX7wAJc2BDFOSS8NpSGbb VLPFA1doMrFOYkL+oMS2IVudM0wEYCBGhGxMi/Y++RY1omlonhEGCoVxaxzGoHrk H/ZpxFheIGBKwo+VX1eSgW9oQZyzbPZttyEWXXNCRh/6oejXCBSS3zkKrWrctmVD ONu1gzoaC9p/c1n2GDioIfxC41dPKdjCETMbTi9rR5shc12ZmwtrgUOU80mpzWj3 6fY+TRW4x8qYbsFL89T6TWGpDz7JrBdtdJiBD/TPtJW05ikn9DTL5/GNVjeeoRk0 5DJ06pHh+rQFKThEvoDdLAH3PZdtDVSdXnAg+gF4D7/BMZ14TLHmW2l471I95S2I eKxZxIwFa2IscTbGKhTlrdPF4UShEvLuFgO6NCb1ea1FT7m3ih8rwA5ObI4676DG Y5kokqi9dpzMB/6T/SDk/gySTg9WUDXFlhS6x/b89f1xC71GzGTJkkqqH4u6KfX8 GcqI3wEFlqpG4FM39XAw =nynZ -END PGP SIGNATURE- -- 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: Help wanted with USB and OMAP3 off_mode
On 01/09/2013 12:29 AM, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). After a suspend/resume cycle with off_mode enabled the GSM module disappears. i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't exist. Without off mode, the modem always appears after resume. I discovered that the registers set by: drivers/mfd/omap-usb-host.c are not maintained across as suspend/resume so I added the following patch (which I can make a formal submission of if it looks right to others), but that didn't help (or didn't help enough). If I echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend thus keeping just the USBHOST power domain out of off_mode, the GSM module doesn't disappear. So it seems that some context in the usbhost domain is not being save and restored. This is as far as I can get. Can someone suggest where I should look to find out what is not being saved/restored properly, and how to go about saving and restoring? You need to ensure that USBHOST/TLL context is saved as per the Save and Restore sequence see section USBHOST/USBTLL Save-and-Restore Management in the OMAP Technical Reference Manual. The basic idea there is that software does the context saving into SAR RAM before entering OFF mode and hardware automatically restores the context after coming out of OFF mode. But that alone is not enough for USB host to work. We need to make sure we have covered all the erratas. There are a number of them which are not covered yet in mainline. USB remote wakeup is another challenge with OMAP USB host (while in OFF mode). The usual workaround here is to use a GPIO as a wakeup line from the modem. regards, -roger -- 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: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 09:26, NeilBrown wrote: On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il wrote: On 01/09/13 14:08, Michael Trimarchi wrote: Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. I've tried various change w.r.t the resetting and I cannot fault it. Resetting or not resetting neither causes a problem while the USB is otherwise working, not fixed the USB while it is otherwise failing. So I don't think this is my problem - thanks. Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for this. I assume this means some patches on top of 3.6.1 ?? Care to share your code? Even horribly ugly hacks can be educational. We are not ready to share these patches (this will happen eventually after some work is finished), but I can explain what they do... We split the ehci_run function to separate the debugfs and sysfs stuff from other initializations, so we can run the new version without the debugfs and sysfs stuff multiple times. Then we implement the suspend/resume ehci callbacks: on suspend, assert phy reset, on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to EHCI_INSNREG04, and call the new ehci_run() function. That does the job for USB host to resume from off mode. Interesting thanks. That makes a certain amount of sense. However I tried compiling ehci-hcd as a module and unload/reloading it which should have a similar net effect to what you did, but it didn't make any difference - device disappears on resume. I also tried restoring the correct value to EHCI_INSNREG04 and EHCI_INSNREG05_ULPI which are the only registers written by ehci-omap.c, and that didn't help either. The only thing I've found that works is keeping 'core' out of off-mode. BTW I discovered that arch/arm/mach-omap2/powerdomains3xxx_data.c comments out the setting of .flags= PWRDM_HAS_HDWR_SAR, for the usbhost powerdomain - that is why I had to leave it in retention. If I uncomment that setting, the it is safe for USBHOST to go to off-mode, just not for CORE. I'll keep exploring. NeilBrown -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIVAwUBUPZ+rznsnt1WYoG5AQLYug//T+J3L11fwVq8JHfiPJVfbEfrAdx96+Id OD+qpwWUarWfpxcgthuRmkrxxUSXxI8sBr0Y0wKWRw4biFxtzcY3qk5xnlUMCfFx BuqrevVZ6bQZ3JDORv1OfeRwZXOheW0ocJ50s1aV8QTTZvrTKo0TNv7G2uLYIssK vafA1WOTQPWAxMd7gx8qjpbT/HPi2kYaLlEJ1/kXYeylGboncUyus42j1q1qnGqy xN6031rpwba4CXtXysx830/uPrnr3LPCh15HUUpxHsYB8rey+60F0ClbT72ZqajJ w1Cy1GR+UDAM7DP3wt1z87H6/IHRXpJLVodUQ5LIZezbWYF1CbAcyJoSyrjZhefe yQnGrFaxHS9oNwaZpDOccxGCPOt8uY5DBRMtEpQKt+3LR0lFJzeICMpfENyMg+3a mU+fzVfGs0puyg/Imcds5yrpmjtGDzuF0yIZ2pIW8pcWjJwbYVzaw9TfzYSSALv1
Re: Help wanted with USB and OMAP3 off_mode
On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros rog...@ti.com wrote: On 01/09/2013 12:29 AM, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). After a suspend/resume cycle with off_mode enabled the GSM module disappears. i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't exist. Without off mode, the modem always appears after resume. I discovered that the registers set by: drivers/mfd/omap-usb-host.c are not maintained across as suspend/resume so I added the following patch (which I can make a formal submission of if it looks right to others), but that didn't help (or didn't help enough). If I echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend thus keeping just the USBHOST power domain out of off_mode, the GSM module doesn't disappear. So it seems that some context in the usbhost domain is not being save and restored. This is as far as I can get. Can someone suggest where I should look to find out what is not being saved/restored properly, and how to go about saving and restoring? You need to ensure that USBHOST/TLL context is saved as per the Save and Restore sequence see section USBHOST/USBTLL Save-and-Restore Management in the OMAP Technical Reference Manual. The basic idea there is that software does the context saving into SAR RAM before entering OFF mode and hardware automatically restores the context after coming out of OFF mode. Is it? The way I read the doco, the hardware both saves to SAR RAM, and restores from SAR RAM. Section 22.2.4.1.6 Save and Restore of my copy of the TRM says: The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host controller (after all USB activity has been suspended) before switching off (=save), save it to an external always-on memory, and reinject it later after the module has been switched on again and reset (=restore) seamlessly for the USB. Part of that context is composed of the register fields described in the current chapter. The rest of the context is composed of the buried flip-flops and memories (not accessible by software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits. which strongly suggests that it is all handled by hardware. Of course there are other registers that aren't covered by the SAR - we need to identify those and make sure they are saved and restored. I've found a few registers that aren't being restored, but restoring them hasn't made a visible difference yet. Am I missing something? But that alone is not enough for USB host to work. We need to make sure we have covered all the erratas. There are a number of them which are not covered yet in mainline. Is there a list somewhere? USB remote wakeup is another challenge with OMAP USB host (while in OFF mode). The usual workaround here is to use a GPIO as a wakeup line from the modem. Yes, this is not a problem for my device. There is a GPIO line which signals and incoming SMS or Call and it successfully wakes the device. regards, -roger Thanks, NeilBrown signature.asc Description: PGP signature
Re: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/16/13 12:19, NeilBrown wrote:
On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/16/13 09:26, NeilBrown wrote:
On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
On 01/09/13 14:08, Michael Trimarchi wrote:
Hi Neil
I forget to answer to your questions
On 01/09/2013 12:34 PM, NeilBrown wrote:
On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
mich...@amarulasolutions.com wrote:
Hi Neil
On 01/09/2013 11:19 AM, NeilBrown wrote:
On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg
grinb...@compulab.co.il
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
On 01/09/13 00:29, NeilBrown wrote:
Hi,
I'm trying to get off_mode working reliably on my gta04 mobile
phone.
My current stumbling block is USB. The Option GSM module is
attached via
USB (there is a separate transceiver chip attached to port 1 which
is placed
in OMAP_EHCI_PORT_MODE_PHY).
Which PHY is this (vendor/model)?
Hi Igor,
it is the SMSC USB3322
http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
BTW I subsequently discovered that keeping USBHOST out off off_mode
only
sometimes avoid the problem, not always. So there are probably
multiple
issues :-(
We have the same PHY and it has some issues with the OMAP USB code.
First issue we experience is that if we reset the PHY more then once
w/o power cycling it, the PHY dies until next power cycle.
So, we stop providing the reset GPIO to the usb code and do the reset
in the board code.
I've tried various change w.r.t the resetting and I cannot fault it.
Resetting or not resetting neither causes a problem while the USB is
otherwise working, not fixed the USB while it is otherwise failing.
So I don't think this is my problem - thanks.
Are you sure that you don't have glitch on power, reset pin during
suspend?
No, I don't really have the equipment to measure such things.
But is it likely? Would enabling off_mode make it more likely?
I don't know the reason of the off_mode problem :(
We have the equipment to check this and no - this is not the case.
Can you suggest some way I could test the hypothesis?
I had the same problem on a rugged mobile phone, so it is just experience
Check the modem power and reset gpio too, but if you don't need to
unblock it
with the pin after resume we know that modem is not the problem
I don't think modem is the problem...
We have plain USB connector ports that are dead after the resume from
off-mode.
The good news are that we have the off-mode working on v3.6.1,
including the USB, but we had to do some horrible ugly hacking for this.
I assume this means some patches on top of 3.6.1 ??
Care to share your code? Even horribly ugly hacks can be educational.
We are not ready to share these patches (this will happen eventually
after some work is finished), but I can explain what they do...
We split the ehci_run function to separate the debugfs and sysfs stuff from
other initializations, so we can run the new version without the debugfs and
sysfs stuff multiple times.
Then we implement the suspend/resume ehci callbacks:
on suspend, assert phy reset,
on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
EHCI_INSNREG04, and call the new ehci_run() function.
That does the job for USB host to resume from off mode.
Interesting thanks. That makes a certain amount of sense.
However I tried compiling ehci-hcd as a module and unload/reloading it which
should have a similar net effect to what you did, but it didn't make any
difference - device disappears on resume.
Yes it does for cm-t3730, in fact, that is what we have started from...
I also tried restoring the correct value to EHCI_INSNREG04 and
EHCI_INSNREG05_ULPI which are the only registers written by
ehci-omap.c, and that didn't help either.
The only thing I've found that works is keeping 'core' out of off-mode.
Ah, one more thing, we ensure that phy is completely powered off through
the TPS power scripts, otherwise, it does not work...
BTW I discovered that arch/arm/mach-omap2/powerdomains3xxx_data.c
comments out the setting of
.flags= PWRDM_HAS_HDWR_SAR,
for the usbhost powerdomain - that is why I had to leave it in retention.
If I uncomment that setting, the it is safe for USBHOST to go to off-mode,
just not for CORE.
I'll keep exploring.
NeilBrown
N?§²æìr¸?yúè?Øb²X¬¶Ç§vØ^?)Þº{.nÇ+?·¥?{±¢f©?{ayº Ê?Ú?ë,j¢f£¢·h??àz¹ ®w¥¢¸
¢·¦j:+v?¨?wèjØm¶?ÿ¾«?êçzZ+?ù???Ý¢j?ú!tml=
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQ9oreAAoJEBDE8YO64EfaRasP/iUDBXhmPQtVm7ESB1DPopMc
b5dUWY1mwQGfNhdcPqApyPk5MPzHTAFfNiLTxJURUqN562gMl1+SR4Mr9cOX6ju4
Re: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 12:19, NeilBrown wrote: On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 09:26, NeilBrown wrote: On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il wrote: On 01/09/13 14:08, Michael Trimarchi wrote: Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. I've tried various change w.r.t the resetting and I cannot fault it. Resetting or not resetting neither causes a problem while the USB is otherwise working, not fixed the USB while it is otherwise failing. So I don't think this is my problem - thanks. Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for this. I assume this means some patches on top of 3.6.1 ?? Care to share your code? Even horribly ugly hacks can be educational. We are not ready to share these patches (this will happen eventually after some work is finished), but I can explain what they do... We split the ehci_run function to separate the debugfs and sysfs stuff from other initializations, so we can run the new version without the debugfs and sysfs stuff multiple times. Then we implement the suspend/resume ehci callbacks: on suspend, assert phy reset, on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to EHCI_INSNREG04, and call the new ehci_run() function. That does the job for USB host to resume from off mode. Interesting thanks. That makes a certain amount of sense. However I tried compiling ehci-hcd as a module and unload/reloading it which should have a similar net effect to what you did, but it didn't make any difference - device disappears on resume. Yes it does for cm-t3730, in fact, that is what we have started from... I also tried restoring the correct value to EHCI_INSNREG04 and EHCI_INSNREG05_ULPI which are the only registers written by ehci-omap.c, and that didn't help either. The only thing I've found that works is keeping 'core' out of off-mode. Ah, one more thing, we ensure that phy is completely powered off through the TPS power scripts, otherwise, it does not work... Ahhh that does make a difference. I turned off the 5V5 rail which powered the phy (and a few other things) and now the usb-attached modem appears after resume. Very interesting. I hadn't been doing this as I had been advised that the hardware wouldn't like it. There are a few devices (including the USB PHY) which are supplied by both a 1V8 rail and the 5V5 rail. Some of them are out-of-spec if the 1V8 is supplied, but the 5V5 isn't. The 1V8 must remain on during suspend
Re: Help wanted with USB and OMAP3 off_mode
On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg grinb...@compulab.co.il wrote: On 01/09/13 14:08, Michael Trimarchi wrote: Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. I've tried various change w.r.t the resetting and I cannot fault it. Resetting or not resetting neither causes a problem while the USB is otherwise working, not fixed the USB while it is otherwise failing. So I don't think this is my problem - thanks. Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for this. I assume this means some patches on top of 3.6.1 ?? Care to share your code? Even horribly ugly hacks can be educational. Thanks, NeilBrown signature.asc Description: PGP signature
Re: Help wanted with USB and OMAP3 off_mode
On Wed, 09 Jan 2013 12:42:43 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? Can you suggest some way I could test the hypothesis? The power pin is connected to a 3v3 regulator which certainly should stay on the whole time and other things which depend on it keep working. The reset line is connected to GPIO174 which is configured: # cat /sys/kernel/debug/omap_mux/mcspi1_cs0 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that didn't appear to make any difference. Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be the off_mode status of the pin. Is it correct? You only set OMAP_PIN_OFF_OUTPUT_HIGH etc if you want the status in offmode to be different to what is was before off mode. In the normal case without any of these bits set, the current value is latched when output in entered and it remains like that that until you leave off_mode. Thanks, NeilBrown signature.asc Description: PGP signature
Re: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
On 01/09/13 00:29, NeilBrown wrote:
Hi,
I'm trying to get off_mode working reliably on my gta04 mobile phone.
My current stumbling block is USB. The Option GSM module is attached via
USB (there is a separate transceiver chip attached to port 1 which is placed
in OMAP_EHCI_PORT_MODE_PHY).
Which PHY is this (vendor/model)?
After a suspend/resume cycle with off_mode enabled the GSM module disappears.
i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
exist.
Without off mode, the modem always appears after resume.
I discovered that the registers set by:
drivers/mfd/omap-usb-host.c
are not maintained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).
If I
echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
thus keeping just the USBHOST power domain out of off_mode, the GSM module
doesn't disappear. So it seems that some context in the usbhost domain is
not being save and restored.
This is as far as I can get. Can someone suggest where I should look to find
out what is not being saved/restored properly, and how to go about saving and
restoring?
Thanks in advance,
NeilBrown
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..522405e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
void __iomem*uhh_base;
+ struct {
+ unsignedhostconfig;
+ } context;
+
struct usbhs_omap_platform_data platdata;
u32 usbhs_rev;
@@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-utmi_p1_fck);
clk_enable(omap-utmi_p2_fck);
+ usbhs_write(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG,
+ omap-context.hostconfig);
+
spin_unlock_irqrestore(omap-lock, flags);
return 0;
@@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
}
spin_lock_irqsave(omap-lock, flags);
+ omap-context.hostconfig = usbhs_read(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG);
if (is_ehci_tll_mode(pdata-port_mode[0]))
clk_disable(omap-usbhost_p1_fck);
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQ7T+kAAoJEBDE8YO64Efaj8YQAI5nOE9vvf8wxbu5IXTxaMxn
6B+g2m/zkMlyVNL5hTrwkPkP4CTBwvsGCZYkZT5JS3KM+R+TuyIX07+eM59Ie0Po
u1CCn2XKZY2CP53b3nAtgk9Phxwruf5fDjEu9QiQapdUpbiTWmIn8W3CVye241O2
wXBKAXszX1bD81NFNY+Jm5Us5uGHNTtNtqe78Rng7BTvmaaNgE61PurFclgn0xQb
IO5E7eyq7TG1u/IBhge2jlZGx2BbLcVsrQI3WyuE2L6F+MRgAKBDD7K8uHTfxPyM
eXAk/u5tbA21t1mTIXk19N4c0YVgeFW2kKQOPShKywy9J6k3tE5LE4yUjooo4ZeS
TlIf7HFcp15N3FfX90FOYsQOXILnoNL6a8SOK3gU+iVxZU/4VohKOXBlMjuZ7o10
5FnglPaHjsEaa1DgB/FcnYh3OO33mODJsckUhi5GiIlrbm70JspfWShZfln1k8FS
SwClmyb6FCiqBOcRJ2uS1KTwObzYV9WeuPGCTXC5d4UBB57eRcGcX/NvSftV57mX
jcSEle93kgZx1EiG53Vwd29oV9nU6SJECF7Q8CqulDEQVr76E7Xh8Z1CrsD+BhKe
XuFa3zdtMg1SZO/ctcTIPPpElCVPF1FChX2lY9fCIdK2luHNrOs4GyrozCGXQcXO
ZMFiiStsjr021CGqQUFw
=yIA2
-END PGP SIGNATURE-
--
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: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
On 01/09/13 00:29, NeilBrown wrote:
Hi,
I'm trying to get off_mode working reliably on my gta04 mobile phone.
My current stumbling block is USB. The Option GSM module is attached via
USB (there is a separate transceiver chip attached to port 1 which is placed
in OMAP_EHCI_PORT_MODE_PHY).
Which PHY is this (vendor/model)?
Hi Igor,
it is the SMSC USB3322
http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
BTW I subsequently discovered that keeping USBHOST out off off_mode only
sometimes avoid the problem, not always. So there are probably multiple
issues :-(
NeilBrown
After a suspend/resume cycle with off_mode enabled the GSM module
disappears.
i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
exist.
Without off mode, the modem always appears after resume.
I discovered that the registers set by:
drivers/mfd/omap-usb-host.c
are not maintained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).
If I
echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
thus keeping just the USBHOST power domain out of off_mode, the GSM module
doesn't disappear. So it seems that some context in the usbhost domain is
not being save and restored.
This is as far as I can get. Can someone suggest where I should look to
find
out what is not being saved/restored properly, and how to go about saving
and
restoring?
Thanks in advance,
NeilBrown
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..522405e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
void __iomem*uhh_base;
+ struct {
+ unsignedhostconfig;
+ } context;
+
struct usbhs_omap_platform_data platdata;
u32 usbhs_rev;
@@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-utmi_p1_fck);
clk_enable(omap-utmi_p2_fck);
+ usbhs_write(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG,
+ omap-context.hostconfig);
+
spin_unlock_irqrestore(omap-lock, flags);
return 0;
@@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
}
spin_lock_irqsave(omap-lock, flags);
+ omap-context.hostconfig = usbhs_read(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG);
if (is_ehci_tll_mode(pdata-port_mode[0]))
clk_disable(omap-usbhost_p1_fck);
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQ7T+kAAoJEBDE8YO64Efaj8YQAI5nOE9vvf8wxbu5IXTxaMxn
6B+g2m/zkMlyVNL5hTrwkPkP4CTBwvsGCZYkZT5JS3KM+R+TuyIX07+eM59Ie0Po
u1CCn2XKZY2CP53b3nAtgk9Phxwruf5fDjEu9QiQapdUpbiTWmIn8W3CVye241O2
wXBKAXszX1bD81NFNY+Jm5Us5uGHNTtNtqe78Rng7BTvmaaNgE61PurFclgn0xQb
IO5E7eyq7TG1u/IBhge2jlZGx2BbLcVsrQI3WyuE2L6F+MRgAKBDD7K8uHTfxPyM
eXAk/u5tbA21t1mTIXk19N4c0YVgeFW2kKQOPShKywy9J6k3tE5LE4yUjooo4ZeS
TlIf7HFcp15N3FfX90FOYsQOXILnoNL6a8SOK3gU+iVxZU/4VohKOXBlMjuZ7o10
5FnglPaHjsEaa1DgB/FcnYh3OO33mODJsckUhi5GiIlrbm70JspfWShZfln1k8FS
SwClmyb6FCiqBOcRJ2uS1KTwObzYV9WeuPGCTXC5d4UBB57eRcGcX/NvSftV57mX
jcSEle93kgZx1EiG53Vwd29oV9nU6SJECF7Q8CqulDEQVr76E7Xh8Z1CrsD+BhKe
XuFa3zdtMg1SZO/ctcTIPPpElCVPF1FChX2lY9fCIdK2luHNrOs4GyrozCGXQcXO
ZMFiiStsjr021CGqQUFw
=yIA2
-END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iQIVAwUBUO1EMznsnt1WYoG5AQJ9Gg//Qwx5P/VjOi+9TDXIGr10OqldLEQKG4zv
Dbwhw5l9DR85JIuF+m5xVXUe9IWJZ0UCasi61LtkRJVGW8U7Lv0O2mmXcYHoQ9zt
diph8SVM9ZTh4SAaz2iiHeJ1Sqz0WkiZ47Kv1C0Q/n9MyFqKKG7Nxg5UAyAj39x4
pa8vsBGcPmwn5U/dUPQBxs3QKdp9aI3i2I6Q6vObRLYLJSvxAeXkGYfrmMy/NoZz
RNhkLhVTajPCYTBcPw+zH06Pv8VF+i/UwFggnVl+uW+6LrIpKbaLa7CMntXmrSgz
fi7y1LLiQuE7qK26IizLu/XIapb0tPGy28AebYwSbjFTaqHPNmlLAzyfww3lBteI
PS76DulKiR4YX58v0KGKITcYLKK3mUliOETcWylot2eTyqbP9m0Y3nX57AEDi0+N
FBBuoG4EKUQaLf5CnjF6ViMttUfvcfwL+Vrn+4VaYndS9S9w5IXTii5b1OcuhJaZ
aGS+Tm/Mwa1uNQWBjujc/DdvwKZRrRilHTBH4w/rHRwxNTqKAxWmq72162efpxdR
JxkHrPTEZZZwLewPXmTbD1+h50284apAw+D2PERFiB+Fh4ZVzsLIcBcUIZ3OT4L1
AlrqYC0wAS2RgjhvmveR360i8DS1SXMMafonrLhrwRu7oe1uzltKmnNX21Sp76vB
gM5LIokwosA=
=8VnD
-END PGP SIGNATURE-
Re: Help wanted with USB and OMAP3 off_mode
Hi Neil
On 01/09/2013 11:19 AM, NeilBrown wrote:
On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
On 01/09/13 00:29, NeilBrown wrote:
Hi,
I'm trying to get off_mode working reliably on my gta04 mobile phone.
My current stumbling block is USB. The Option GSM module is attached via
USB (there is a separate transceiver chip attached to port 1 which is placed
in OMAP_EHCI_PORT_MODE_PHY).
Which PHY is this (vendor/model)?
Hi Igor,
it is the SMSC USB3322
http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
BTW I subsequently discovered that keeping USBHOST out off off_mode only
sometimes avoid the problem, not always. So there are probably multiple
issues :-(
Are you sure that you don't have glitch on power, reset pin during suspend?
Michael
NeilBrown
After a suspend/resume cycle with off_mode enabled the GSM module
disappears.
i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
exist.
Without off mode, the modem always appears after resume.
I discovered that the registers set by:
drivers/mfd/omap-usb-host.c
are not maintained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).
If I
echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
thus keeping just the USBHOST power domain out of off_mode, the GSM module
doesn't disappear. So it seems that some context in the usbhost domain is
not being save and restored.
This is as far as I can get. Can someone suggest where I should look to
find
out what is not being saved/restored properly, and how to go about saving
and
restoring?
Thanks in advance,
NeilBrown
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..522405e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
void __iomem*uhh_base;
+ struct {
+ unsignedhostconfig;
+ } context;
+
struct usbhs_omap_platform_data platdata;
u32 usbhs_rev;
@@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-utmi_p1_fck);
clk_enable(omap-utmi_p2_fck);
+ usbhs_write(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG,
+ omap-context.hostconfig);
+
spin_unlock_irqrestore(omap-lock, flags);
return 0;
@@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
}
spin_lock_irqsave(omap-lock, flags);
+ omap-context.hostconfig = usbhs_read(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG);
if (is_ehci_tll_mode(pdata-port_mode[0]))
clk_disable(omap-usbhost_p1_fck);
- --
Regards,
Igor.
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±¢f©Š{ayº ʇڙë,j¢f£¢·hš‹àz¹ ®w¥¢¸
¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝ¢j�ú!tml=
--
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: Help wanted with USB and OMAP3 off_mode
On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? Can you suggest some way I could test the hypothesis? The power pin is connected to a 3v3 regulator which certainly should stay on the whole time and other things which depend on it keep working. The reset line is connected to GPIO174 which is configured: # cat /sys/kernel/debug/omap_mux/mcspi1_cs0 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that didn't appear to make any difference. Thanks, NeilBrown signature.asc Description: PGP signature
Re: Help wanted with USB and OMAP3 off_mode
On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? Can you suggest some way I could test the hypothesis? The power pin is connected to a 3v3 regulator which certainly should stay on the whole time and other things which depend on it keep working. The reset line is connected to GPIO174 which is configured: # cat /sys/kernel/debug/omap_mux/mcspi1_cs0 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that didn't appear to make any difference. Can you try to add this OMAP_PIN_OFF_OUTPUT_HIGH or LOW? It's suppose to be the off_mode status of the pin. Is it correct? Michael Thanks, NeilBrown -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | -- 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: Help wanted with USB and OMAP3 off_mode
Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem Michael The power pin is connected to a 3v3 regulator which certainly should stay on the whole time and other things which depend on it keep working. The reset line is connected to GPIO174 which is configured: # cat /sys/kernel/debug/omap_mux/mcspi1_cs0 name: mcspi1_cs0.gpio_174 (0x480021ce/0x19e = 0x011c), b ac2, t NA mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE4 signals: mcspi1_cs0 | sdmmc2_dat7 | NA | NA | gpio_174 | NA | NA | safe_mode The PIN_INPUT seems a bit odd, so I changed it to OMAP_PIN_OUTPUT but that didn't appear to make any difference. Thanks, NeilBrown -- 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: Help wanted with USB and OMAP3 off_mode
On 01/09/13 14:08, Michael Trimarchi wrote: Hi Neil I forget to answer to your questions On 01/09/2013 12:34 PM, NeilBrown wrote: On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi mich...@amarulasolutions.com wrote: Hi Neil On 01/09/2013 11:19 AM, NeilBrown wrote: On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/09/13 00:29, NeilBrown wrote: Hi, I'm trying to get off_mode working reliably on my gta04 mobile phone. My current stumbling block is USB. The Option GSM module is attached via USB (there is a separate transceiver chip attached to port 1 which is placed in OMAP_EHCI_PORT_MODE_PHY). Which PHY is this (vendor/model)? Hi Igor, it is the SMSC USB3322 http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf BTW I subsequently discovered that keeping USBHOST out off off_mode only sometimes avoid the problem, not always. So there are probably multiple issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. Are you sure that you don't have glitch on power, reset pin during suspend? No, I don't really have the equipment to measure such things. But is it likely? Would enabling off_mode make it more likely? I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. Can you suggest some way I could test the hypothesis? I had the same problem on a rugged mobile phone, so it is just experience Check the modem power and reset gpio too, but if you don't need to unblock it with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for this. -- Regards, Igor. -- 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
Help wanted with USB and OMAP3 off_mode
Hi,
I'm trying to get off_mode working reliably on my gta04 mobile phone.
My current stumbling block is USB. The Option GSM module is attached via
USB (there is a separate transceiver chip attached to port 1 which is placed
in OMAP_EHCI_PORT_MODE_PHY).
After a suspend/resume cycle with off_mode enabled the GSM module disappears.
i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
exist.
Without off mode, the modem always appears after resume.
I discovered that the registers set by:
drivers/mfd/omap-usb-host.c
are not maintained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).
If I
echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
thus keeping just the USBHOST power domain out of off_mode, the GSM module
doesn't disappear. So it seems that some context in the usbhost domain is
not being save and restored.
This is as far as I can get. Can someone suggest where I should look to find
out what is not being saved/restored properly, and how to go about saving and
restoring?
Thanks in advance,
NeilBrown
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..522405e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
void __iomem*uhh_base;
+ struct {
+ unsignedhostconfig;
+ } context;
+
struct usbhs_omap_platform_data platdata;
u32 usbhs_rev;
@@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-utmi_p1_fck);
clk_enable(omap-utmi_p2_fck);
+ usbhs_write(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG,
+ omap-context.hostconfig);
+
spin_unlock_irqrestore(omap-lock, flags);
return 0;
@@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
}
spin_lock_irqsave(omap-lock, flags);
+ omap-context.hostconfig = usbhs_read(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG);
if (is_ehci_tll_mode(pdata-port_mode[0]))
clk_disable(omap-usbhost_p1_fck);
signature.asc
Description: PGP signature
Re: need help debugging ISP problem
Hi Adam, On Monday 05 November 2012 16:02:08 Adam Wozniak wrote: I'm working with a custom board based on an Overo WaterStorm com. The processor is a DM3730. The kernel is 2.6.32 based. 2.6.32 very probably means you're using the old TI driver. Please don't. That's buggy and totally unsupported. I advice upgrading to the latest mainline kernel. I'm trying to stress test the camera ISP by rapidly opening and closing the video device with ( while true; do gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! pngenc snapshot=true ! fakesink; done ) After many iterations, I will see the kernel spit out: [ 2502.802795] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0bce04 [ 2502.810516] Internal error: : 1028 [#1] [ ... ] [ 2502.846893] PC is at isp_reg_readl+0x18/0x20 [ 2502.851196] LR is at isp_reg_readl+0x10/0x20 [ ... ] [ 2503.296447] [c02954a0] (isp_reg_readl+0x18/0x20) from [c02954f8] (isp_reg_and_or+0x1c/0x38) [ 2503.305206] [c02954f8] (isp_reg_and_or+0x1c/0x38) from [c029bad0] (isppreview_config_cfa+0x38/0x90) [ 2503.314666] [c029bad0] (isppreview_config_cfa+0x38/0x90) from [c029bc5c] (isppreview_config_datapath+0x134/0x330) [ 2503.325347] [c029bc5c] (isppreview_config_datapath+0x134/0x330) from [c029be68] (isppreview_s_pipeline+0x10/0xd0) [ 2503.336029] [c029be68] (isppreview_s_pipeline+0x10/0xd0) from [c0296e98] (isp_s_pipeline+0x1d8/0x280) [ 2503.345672] [c0296e98] (isp_s_pipeline+0x1d8/0x280) from [bf036b98] (cammux_streamon+0x218/0xa28 [cammux]) [ ... ] The register we're trying to access here is the ISP PRV_PCR. If I try to add debug code to read ISP_CTRL right before the fault, the ISP_CTRL access faults in the same way (i.e. the whole ISP is borked, not just the previewer). At first I thought the clocks were being disabled somehow, but tracking them seems to indicate that's not the case. Adding an early return in arch/arm/mach/omap2/clock.c omap2_dflt_clk_disable() (i.e. to disable disabling of clocks) does NOT help. What else might I be missing? What is necessary to be able to read the ISP registers? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
need help debugging ISP problem
I'm working with a custom board based on an Overo WaterStorm com. The processor is a DM3730. The kernel is 2.6.32 based. I'm trying to stress test the camera ISP by rapidly opening and closing the video device with ( while true; do gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! pngenc snapshot=true ! fakesink; done ) After many iterations, I will see the kernel spit out: [ 2502.802795] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0bce04 [ 2502.810516] Internal error: : 1028 [#1] [ ... ] [ 2502.846893] PC is at isp_reg_readl+0x18/0x20 [ 2502.851196] LR is at isp_reg_readl+0x10/0x20 [ ... ] [ 2503.296447] [c02954a0] (isp_reg_readl+0x18/0x20) from [c02954f8] (isp_reg_and_or+0x1c/0x38) [ 2503.305206] [c02954f8] (isp_reg_and_or+0x1c/0x38) from [c029bad0] (isppreview_config_cfa+0x38/0x90) [ 2503.314666] [c029bad0] (isppreview_config_cfa+0x38/0x90) from [c029bc5c] (isppreview_config_datapath+0x134/0x330) [ 2503.325347] [c029bc5c] (isppreview_config_datapath+0x134/0x330) from [c029be68] (isppreview_s_pipeline+0x10/0xd0) [ 2503.336029] [c029be68] (isppreview_s_pipeline+0x10/0xd0) from [c0296e98] (isp_s_pipeline+0x1d8/0x280) [ 2503.345672] [c0296e98] (isp_s_pipeline+0x1d8/0x280) from [bf036b98] (cammux_streamon+0x218/0xa28 [cammux]) [ ... ] The register we're trying to access here is the ISP PRV_PCR. If I try to add debug code to read ISP_CTRL right before the fault, the ISP_CTRL access faults in the same way (i.e. the whole ISP is borked, not just the previewer). At first I thought the clocks were being disabled somehow, but tracking them seems to indicate that's not the case. Adding an early return in arch/arm/mach/omap2/clock.c omap2_dflt_clk_disable() (i.e. to disable disabling of clocks) does NOT help. What else might I be missing? What is necessary to be able to read the ISP registers? --Adam -- 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: Help needed with remaining plat headers
Hi, On 09/28/2012 09:58 AM, Vutla, Lokesh wrote: Hi, I see a module build failure in linux-next tree. Any one else facing this issue or I am missing something. Using master branch on git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Below is the log . $ make modules -j 10 ERROR: snd_hwparams_to_dma_slave_config [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_pointer [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_open [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_close [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_get_chan [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_trigger [sound/soc/omap/snd-soc-omap.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 I have sent a patch fixing this (which also affect other platforms as well): http://mailman.alsa-project.org/pipermail/alsa-devel/2012-October/055902.html -- 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
Re: Help needed with remaining plat headers
Hi, I see a module build failure in linux-next tree. Any one else facing this issue or I am missing something. Using master branch on git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Below is the log . $ make modules -j 10 CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CC [M] sound/sound_core.o CC [M] crypto/ecb.o CC [M] crypto/arc4.o CC [M] sound/core/compress_offload.o CC [M] drivers/base/regmap/regmap-spi.o CC [M] sound/core/hwdep.o CC [M] net/bluetooth/af_bluetooth.o CC [M] drivers/bluetooth/hci_ldisc.o CC [M] drivers/bluetooth/hci_h4.o CC [M] net/bluetooth/hci_core.o CC [M] drivers/bluetooth/hci_bcsp.o CC [M] drivers/bluetooth/hci_ll.o CC [M] drivers/bluetooth/bcm203x.o CC [M] sound/core/memalloc.o CC [M] drivers/bluetooth/bpa10x.o CC [M] sound/core/pcm.o LD [M] drivers/bluetooth/hci_uart.o CC [M] net/bluetooth/hci_conn.o CC [M] sound/core/pcm_native.o CC [M] sound/core/pcm_lib.o CC [M] net/bluetooth/hci_event.o CC [M] sound/core/pcm_timer.o CC [M] net/bluetooth/mgmt.o CC [M] sound/core/pcm_misc.o CC [M] sound/core/pcm_memory.o CC [M] net/mac80211/main.o CC [M] drivers/net/wireless/libertas/cfg.o CC [M] net/mac80211/status.o CC [M] sound/core/rawmidi.o CC [M] sound/core/timer.o CC [M] sound/core/sound.o CC [M] sound/core/init.o CC [M] sound/soc/soc-core.o CC [M] sound/core/memory.o CC [M] net/mac80211/sta_info.o CC [M] net/mac80211/wep.o CC [M] net/mac80211/wpa.o CC [M] net/mac80211/scan.o CC [M] net/mac80211/offchannel.o CC [M] net/bluetooth/hci_sock.o CC [M] drivers/net/wireless/libertas/cmd.o CC [M] net/bluetooth/hci_sysfs.o CC [M] sound/core/info.o CC [M] net/mac80211/ht.o CC [M] net/mac80211/agg-tx.o CC [M] sound/core/control.o CC [M] sound/core/misc.o CC [M] sound/core/device.o CC [M] sound/soc/soc-dapm.o CC [M] net/bluetooth/l2cap_core.o CC [M] drivers/net/wireless/libertas/cmdresp.o CC [M] net/bluetooth/l2cap_sock.o CC [M] net/bluetooth/smp.o CC [M] net/bluetooth/sco.o CC [M] sound/soc/soc-jack.o CC [M] net/mac80211/agg-rx.o CC [M] drivers/net/wireless/libertas/debugfs.o CC [M] drivers/net/wireless/libertas/ethtool.o CC [M] drivers/net/wireless/libertas/main.o CC [M] sound/core/sound_oss.o CC [M] sound/core/info_oss.o CC [M] net/bluetooth/lib.o CC [M] net/bluetooth/a2mp.o CC [M] net/mac80211/ibss.o CC [M] drivers/net/wireless/libertas/rx.o CC [M] drivers/net/wireless/libertas/tx.o CC [M] sound/core/jack.o CC [M] drivers/net/wireless/libertas/firmware.o CC [M] sound/soc/soc-cache.o CC [M] sound/core/oss/mixer_oss.o CC [M] drivers/net/wireless/libertas/if_sdio.o CC [M] drivers/net/wireless/libertas/if_usb.o CC [M] sound/soc/soc-utils.o CC [M] net/mac80211/iface.o CC [M] net/wireless/core.o CC [M] net/wireless/sysfs.o CC [M] sound/core/oss/pcm_oss.o CC [M] sound/soc/soc-pcm.o CC [M] sound/usb/card.o LD [M] net/bluetooth/bluetooth.o CC [M] net/wireless/radiotap.o CC [M] sound/core/oss/pcm_plugin.o CC [M] sound/core/oss/io.o CC [M] net/wireless/util.o LD [M] drivers/net/wireless/libertas/libertas.o LD [M] drivers/net/wireless/libertas/usb8xxx.o LD [M] drivers/net/wireless/libertas/libertas_sdio.o CC [M] net/wireless/reg.o CC [M] sound/soc/soc-compress.o CC [M] sound/usb/clock.o CC [M] sound/soc/soc-io.o CC [M] net/mac80211/rate.o CC [M] sound/usb/endpoint.o CC [M] net/wireless/scan.o CC [M] net/wireless/nl80211.o CC [M] sound/core/oss/copy.o CC [M] drivers/usb/gadget/zero.o CC [M] sound/soc/codecs/twl4030.o CC [M] drivers/usb/gadget/usbstring.o CC [M] sound/core/oss/linear.o CC [M] drivers/usb/gadget/config.o CC [M] sound/usb/format.o CC [M] net/mac80211/michael.o CC [M] net/mac80211/tkip.o CC [M] drivers/video/cfbfillrect.o CC [M] sound/core/oss/mulaw.o CC [M] sound/core/oss/route.o CC [M] drivers/usb/gadget/epautoconf.o CC [M] drivers/usb/gadget/composite.o CC [M] drivers/video/cfbcopyarea.o CC [M] sound/usb/helper.o LD [M] sound/soc/codecs/snd-soc-twl4030.o CC [M] sound/usb/mixer.o CC [M] sound/usb/mixer_quirks.o CC [M] sound/core/oss/rate.o CC [M] sound/usb/pcm.o CC [M] sound/soc/omap/omap-mcbsp.o CC [M] sound/soc/omap/mcbsp.o LD [M] sound/core/oss/snd-mixer-oss.o LD [M] sound/core/oss/snd-pcm-oss.o LD [M] sound/core/snd.o LD [M] sound/core/snd-hwdep.o LD [M] sound/core/snd-timer.o LD [M] sound/core/snd-pcm.o LD [M] sound/core/snd-page-alloc.o LD [M] sound/core/snd-rawmidi.o LD [M] sound/core/snd-compress.o CC [M] drivers/video/cfbimgblt.o CC [M] sound/soc/omap/omap-pcm.o CC [M] net/wireless/mlme.o CC [M] net/mac80211/aes_ccm.o CC [M] net/wireless/ibss.o CC [M]
linux-next ASOC build break ? (Was... Re: Help needed with remaining plat headers)
+ Peter, Liam in case they haven't seen the issue yet. On Fri, Sep 28, 2012 at 12:28 PM, Vutla, Lokesh lokeshvu...@ti.com wrote: Hi, I see a module build failure in linux-next tree. Any one else facing this issue or I am missing something. Using master branch on git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Below is the log . $ make modules -j 10 CHK include/linux/version.h CHK include/generated/utsrelease.h LD [M] drivers/video/omap2/dss/omapdss.o Building modules, stage 2. [..] MODPOST 45 modules ERROR: snd_hwparams_to_dma_slave_config [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_pointer [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_open [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_close [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_get_chan [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_trigger [sound/soc/omap/snd-soc-omap.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help needed with remaining plat headers
On 09/27/2012 12:57 PM, Vutla, Lokesh wrote: clkdev_omap.h clock.h common.h cpu.h dma-44xx.h dma.h As a part of clean up I am looking at dma.h and dma-44xx.h files ll send you patches once cleanup and testing is done. One note for the dma.h, dma-44xx.h: The audio drivers used to include at least dma.h, but after the dmaengine conversion the are no longer doing it. The dmaengine for OMAP audio is going for 3.7. You can see them for some time in linux-next laready. -- 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
Re: Help needed with remaining plat headers
Hi Peter, On Fri, Sep 28, 2012 at 2:24 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 09/27/2012 12:57 PM, Vutla, Lokesh wrote: clkdev_omap.h clock.h common.h cpu.h dma-44xx.h dma.h As a part of clean up I am looking at dma.h and dma-44xx.h files ll send you patches once cleanup and testing is done. One note for the dma.h, dma-44xx.h: The audio drivers used to include at least dma.h, but after the dmaengine conversion the are no longer doing it. The dmaengine for OMAP audio is going for 3.7. You can see them for some time in linux-next laready. Yes I am aware of this. I am making patches on linux-next only Thanks Lokesh -- 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
Re: Help needed with remaining plat headers
Hi Tony, On 09/27/2012 03:26 PM, Tony Lindgren wrote: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. [snip] dmtimer.h Jon, can you do a patch for dmtimer.h? Yes, I will look into this. Cheers Jon -- 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: Help needed with remaining plat headers
Hi Tony, On Fri, Sep 21, 2012 at 4:59 AM, Tony Lindgren t...@atomide.com wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple for most of them: 1. For driver related data, the header should now be in include/linux/platform_data/*.h 2. For mach-omap2 specific things, the headers should be in arch/arm/mach-omap2. 3. Drivers should not include anything from plat or mach. I'll be looking into getting rid of cpu.h etc for v3.8 merge window, but won't be looking much at the driver related headers. So some help would be appreciated here :) Regards, Tony $ ls arch/arm/plat-omap/include/plat/ clkdev_omap.h clock.h common.h cpu.h dma-44xx.h dma.h As a part of clean up I am looking at dma.h and dma-44xx.h files ll send you patches once cleanup and testing is done. Thanks Lokesh dmtimer.h fpga.h gpmc.h i2c.h iommu2.h iommu.h iopgtable.h iovmm.h led.h mailbox.h menelaus.h mmc.h multi.h omap_device.h omap_hwmod.h omap-pm.h omap-secure.h omap-serial.h prcm.h sdrc.h serial.h sram.h tc.h timex.h uncompress.h usb.h vram.h vrfb.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Help needed with remaining plat headers
On Thu, 2012-09-20 at 16:29 -0700, Tony Lindgren wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple vram.h vrfb.h I'll work on these ones. Tomi signature.asc Description: This is a digitally signed message part
Re: Help needed with remaining plat headers
* Tomi Valkeinen tomi.valkei...@ti.com [120927 03:13]: On Thu, 2012-09-20 at 16:29 -0700, Tony Lindgren wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple vram.h vrfb.h I'll work on these ones. Thanks. Can you please also remove the remaining cpu_is_omap and soc_is_omap usage from drivers/video for omap2+ early with some patches that I can apply to my cleanup branch early? 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: Help needed with remaining plat headers
* Vutla, Lokesh lokeshvu...@ti.com [120927 02:59]: dma-44xx.h dma.h As a part of clean up I am looking at dma.h and dma-44xx.h files ll send you patches once cleanup and testing is done. OK great that's good to hear. 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: Help needed with remaining plat headers
Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ clkdev_omap.h clock.h Paul posted patches for the clock headers. common.h I'll make common.h local. cpu.h Making cpu.h local requires getting rid of cpu_is_omap/soc_is_omap usage in drivers for mach-omap2+, so please fix your drivers! dma-44xx.h dma.h Lokesh will post patches for the dma*.h files. dmtimer.h Jon, can you do a patch for dmtimer.h? fpga.h I'll make fpga.h local to mach-omap1. gpmc.h Afzal, can you do a patch for gpmc.h? i2c.h Will move to platform_data after defining register functions locally. iommu2.h iommu.h iopgtable.h iovmm.h There are io*.h patches posted for these by Ido that need a bit more work to clear out the non-platform-data parts that should be local to the driver. led.h Will move to platform_data. mailbox.h Omar, can you please do a patch that makes mailbox.h suitable for include/linux/platform_data/mailbox-omap.h? menelaus.h Will convert to be suitable for include/linux/platform_data. mmc.h Will convert to be suitable for include/linux/platform_data. multi.h Will make multi.h local. omap_device.h omap_hwmod.h Will make omap_device.h and omap_hwmod.h local to mach-omap2. omap-pm.h omap-secure.h omap-serial.h Will fix up for platform_data/serial-omap.h. prcm.h sdrc.h Will make prcm.h and sdrc.h local to mach-omap2. serial.h Will fix up for platform_data/serial-omap.h. sram.h Will make sram.h local. tc.h Will make tc.h local to mach-omap1. timex.h Igor is looking into timex.h. uncompress.h We can just move and disable the DEBUG_LL unless UART address + shift are specified in Kconfig in a generic way. I think this is already possible or patches have been posted to LAKML? usb.h Felipe can you do a patch for this one? vram.h vrfb.h Tomi will post patches for vr*.h files. 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: Help needed with remaining plat headers
Missed omap-pm.h and omap-secure.h, see below.. * Tony Lindgren t...@atomide.com [120927 13:27]: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ clkdev_omap.h clock.h Paul posted patches for the clock headers. common.h I'll make common.h local. cpu.h Making cpu.h local requires getting rid of cpu_is_omap/soc_is_omap usage in drivers for mach-omap2+, so please fix your drivers! dma-44xx.h dma.h Lokesh will post patches for the dma*.h files. dmtimer.h Jon, can you do a patch for dmtimer.h? fpga.h I'll make fpga.h local to mach-omap1. gpmc.h Afzal, can you do a patch for gpmc.h? i2c.h Will move to platform_data after defining register functions locally. iommu2.h iommu.h iopgtable.h iovmm.h There are io*.h patches posted for these by Ido that need a bit more work to clear out the non-platform-data parts that should be local to the driver. led.h Will move to platform_data. mailbox.h Omar, can you please do a patch that makes mailbox.h suitable for include/linux/platform_data/mailbox-omap.h? menelaus.h Will convert to be suitable for include/linux/platform_data. mmc.h Will convert to be suitable for include/linux/platform_data. multi.h Will make multi.h local. omap_device.h omap_hwmod.h Will make omap_device.h and omap_hwmod.h local to mach-omap2. omap-pm.h I think Kevin already has some patches to make this local? omap-secure.h Will make omap-secure.h local. omap-serial.h Will fix up for platform_data/serial-omap.h. prcm.h sdrc.h Will make prcm.h and sdrc.h local to mach-omap2. serial.h Will fix up for platform_data/serial-omap.h. sram.h Will make sram.h local. tc.h Will make tc.h local to mach-omap1. timex.h Igor is looking into timex.h. uncompress.h We can just move and disable the DEBUG_LL unless UART address + shift are specified in Kconfig in a generic way. I think this is already possible or patches have been posted to LAKML? usb.h Felipe can you do a patch for this one? vram.h vrfb.h Tomi will post patches for vr*.h files. 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: Help needed with remaining plat headers
On Fri, Sep 28, 2012 at 1:56 AM, Tony Lindgren t...@atomide.com wrote: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ [..] omap-secure.h Will work with Lokesh to get this one sorted out along with dma. It can be made local to mach-omap2. Regards Santosh -- 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: Help needed with remaining plat headers
* Shilimkar, Santosh santosh.shilim...@ti.com [120927 13:34]: On Fri, Sep 28, 2012 at 1:56 AM, Tony Lindgren t...@atomide.com wrote: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ [..] omap-secure.h Will work with Lokesh to get this one sorted out along with dma. It can be made local to mach-omap2. OK 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: Help needed with remaining plat headers
Hi Tony, On Fri, Sep 28, 2012 at 01:56:16, Tony Lindgren wrote: Please see below a status update on the remaining problem plat headers. gpmc.h Afzal, can you do a patch for gpmc.h? Yes, I will do it. Regards Afzal
Re: Help needed with remaining plat headers
On 09/21/12 02:29, Tony Lindgren wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple for most of them: 1. For driver related data, the header should now be in include/linux/platform_data/*.h 2. For mach-omap2 specific things, the headers should be in arch/arm/mach-omap2. 3. Drivers should not include anything from plat or mach. I'll be looking into getting rid of cpu.h etc for v3.8 merge window, but won't be looking much at the driver related headers. So some help would be appreciated here :) Regards, Tony $ ls arch/arm/plat-omap/include/plat/ [...] timex.h I'll try to deal with this one, as it is related to the work I currently do for CONFIG_OMAP_32K_TIMER removal. Probably for v3.8 merge window. -- Regards, Igor. -- 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: Help needed with remaining plat headers
* Igor Grinberg grinb...@compulab.co.il [120921 02:07]: On 09/21/12 02:29, Tony Lindgren wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple for most of them: 1. For driver related data, the header should now be in include/linux/platform_data/*.h Just to clarify this, these headers should only contain the platform data shared between the SoC specific code and driver. Things that are driver internal should be in the driver specific header or moved to the driver. Things that are SoC internal should be in the local *.[chS] files in the arch/arm/mach-omap2 directory. 2. For mach-omap2 specific things, the headers should be in arch/arm/mach-omap2. 3. Drivers should not include anything from plat or mach. I'll be looking into getting rid of cpu.h etc for v3.8 merge window, but won't be looking much at the driver related headers. So some help would be appreciated here :) Regards, Tony $ ls arch/arm/plat-omap/include/plat/ [...] timex.h I'll try to deal with this one, as it is related to the work I currently do for CONFIG_OMAP_32K_TIMER removal. Probably for v3.8 merge window. OK great 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
Help needed with remaining plat headers
Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple for most of them: 1. For driver related data, the header should now be in include/linux/platform_data/*.h 2. For mach-omap2 specific things, the headers should be in arch/arm/mach-omap2. 3. Drivers should not include anything from plat or mach. I'll be looking into getting rid of cpu.h etc for v3.8 merge window, but won't be looking much at the driver related headers. So some help would be appreciated here :) Regards, Tony $ ls arch/arm/plat-omap/include/plat/ clkdev_omap.h clock.h common.h cpu.h dma-44xx.h dma.h dmtimer.h fpga.h gpmc.h i2c.h iommu2.h iommu.h iopgtable.h iovmm.h led.h mailbox.h menelaus.h mmc.h multi.h omap_device.h omap_hwmod.h omap-pm.h omap-secure.h omap-serial.h prcm.h sdrc.h serial.h sram.h tc.h timex.h uncompress.h usb.h vram.h vrfb.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Help]: Omap-serial: UART DMA Engine
Hi Russell, I am currently working on implementing DMA Engine for omap serial driver. Came to know from santosh that you had suggested that certain modification need to be done in the tty core layer, which I am unaware of. Can you please explain what sort of changes need to be done? -- 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: Help required on N900
On Thu, Jul 5, 2012 at 10:21 AM, Mohammed, Afzal af...@ti.com wrote: Hi, Can someone please provide me with a link to N900 board schematics. It would be really helpful if information on how to do Numonyx OneNAND reset on N900 (i.e. like how long reset signal should be asserted), and gpio pin number connected (if connected) to OneNAND reset pin can be provided. I guess this should help: http://maemo.jacekowski.org/docs/ -- 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: Please help! AM35xx mm/slab.c BUG
Hi,
On Tue, Jun 19, 2012 at 06:59:42, CF Adad wrote:
Anyway, we have advanced our kernel to today's latest l-o (3.5-rc2). Though
we are not considering the GPMC a likely source of the error at this moment,
I'm considering exploring this patchset. Unfortunately, the NAND is very
critical to our current efforts. So I'm trying to find a time where it would
be OK to disable it as you suggested to try this. Since these values are
being set now in Linux, do I need to rework my bootloaders as well? In my
current case, these settings are all done in u-boot. I do not believe Linux
did anything with them. Do I need to remove those in order to use your
patches? If I do, do I not lose access to those things while in the
bootloaders?
Please sent me your board file, I will modify it to use the
new interface with NAND relying on bootloader settings and
SMSC relying on Kernel.
No bootloader modifications are required.
Regards
Afzal
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html
[3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html
[4] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69897.html
[5] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69917.html
[5.x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69924.html
[6]
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 4bfe721..34816b9 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -105,12 +105,12 @@ static void gpmc_smsc911x_timing(struct gpmc_time_ctrl
*time_ctrl,
{
struct gpmc_timings t;
/* SMSC 9220 timings */
- unsigned tcycle_r = 165;
+ unsigned tcycle_r = 45;
unsigned tcsl_r = 32;
unsigned tcsh_r = 133;
unsigned tcsdv_r = 30;
unsigned tdoff_r = 9;
- unsigned tcycle_w = 165;
+ unsigned tcycle_w = 45;
unsigned tcsl_w = 32;
unsigned tcsh_w = 133;
unsigned tdsu_w = 7;
--
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
