Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, 08 Jan 2013, Arnd Bergmann wrote: On Tuesday 08 January 2013, Pantelis Antoniou wrote: On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote: On Tuesday 08 January 2013, Lee Jones wrote: If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( I thought that some of the newer UIBs had it, just not the old ones. As Pantelis says, we could at least detect the ones that have an EEPROM on them, and use a command line option or device tree attribute for the others. Arnd So I gather the new ones have an eeprom? I don't remember the details unfortunately. Lee should be the one who can find out. IIRC there was at least a single integeger number on them. Not as far as I can remember. There was (is?) a crude method of identifying UIBs, but attempting to obtain certain I2C lines and testing which ones were accessible. However, if there is an issue with I2C, the wrong UIB was 'probed'. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones lee.jo...@linaro.org wrote:
On Tue, 08 Jan 2013, Arnd Bergmann wrote:
On Tuesday 08 January 2013, Pantelis Antoniou wrote:
On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
On Tuesday 08 January 2013, Lee Jones wrote:
If there is not, there is no way to automatically load the overlays;
you can always
use the kernel command line, or have the a user space application to
request the loading
of a specific board's overlay.
Unfortunately, there is no way to probe the UIBs. :(
I thought that some of the newer UIBs had it, just not the old ones.
As Pantelis says, we could at least detect the ones that have an EEPROM
on them, and use a command line option or device tree attribute for the
others.
Arnd
So I gather the new ones have an eeprom?
I don't remember the details unfortunately. Lee should be the one who can
find out.
IIRC there was at least a single integeger number on them.
Not as far as I can remember. There was (is?) a crude method of
identifying UIBs, but attempting to obtain certain I2C lines and
testing which ones were accessible. However, if there is an issue
with I2C, the wrong UIB was 'probed'.
Right, so the UIBs had different GPIO expanders on some I2C addresses,
so we attempt to communicate with the expander to see if it's board type A,
and if it doesn't respond it's deemed to be board type B.
This is the code:
arch/arm/mach-ux500/board-mop500-uib.c
/*
* Detect the UIB attached based on the presence or absence of i2c devices.
*/
int __init mop500_uib_init(void)
{
struct uib *uib = mop500_uib;
struct i2c_adapter *i2c0;
int ret;
if (!cpu_is_u8500_family())
return -ENODEV;
if (uib) {
__mop500_uib_init(uib, from uib= boot argument);
return 0;
}
i2c0 = i2c_get_adapter(0);
if (!i2c0) {
__mop500_uib_init(mop500_uibs[STUIB],
fallback, could not get i2c0);
return -ENODEV;
}
/* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
I2C_SMBUS_QUICK, NULL);
i2c_put_adapter(i2c0);
if (ret == 0)
uib = mop500_uibs[U8500UIB];
else
uib = mop500_uibs[STUIB];
__mop500_uib_init(uib, detected);
return 0;
}
Not elegant but better than e.g. passing a kernel command line option.
As you say it has the downside of detecting the wrong UIB if there is
some (other) problem with the I2C block. But in that case the system is
likely borked anyway so I wonder if it matters...
Even with the device tree approach we'd be into trouble if say, the UIB
was unplugged (which is perfectly possible). The device tree cannot
detect that.
The larger question is how to handle, at runtime, hardware that may
or may not be present, in a device tree world.
Compare this other case: the Integrator has pluggable daughterboards,
(called LMs, logic modules) and in that case we have specific registers
to detect them, and register the daughter board on this specific bus
that Russell came up with in arch/arm/mach-integrator/lm.c,
the actual board detection is in arch/arm/mach-integrator/integrator_ap.c:
static void __init ap_init(void)
{
unsigned long sc_dec;
int i;
platform_device_register(cfi_flash_device);
sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
for (i = 0; i 4; i++) {
struct lm_device *lmdev;
if ((sc_dec (16 i)) == 0)
continue;
lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
if (!lmdev)
continue;
lmdev-resource.start = 0xc000 + 0x1000 * i;
lmdev-resource.end = lmdev-resource.start + 0x0fff;
lmdev-resource.flags = IORESOURCE_MEM;
lmdev-irq = IRQ_AP_EXPINT0 + i;
lmdev-id = i;
lm_device_register(lmdev);
}
integrator_init(false);
}
In this case I think the autodetect is so nice that device tree probing
is mostly pointless. If it wasn't for the fact that we get a
cross-depenency to defined interrupts and clocks and whatever that
are coming from the device tree. Which is where DT shows its
all-or-nothing face.
So to get an elegant DT probing in this case I *guess* the right thing
to do is to dynamically add nodes to the device tree from the board
code, or have all alternatives inside the DT marked disable and then
mark them as okay from the board code by modifying the DT at
runtime.
Ideas welcome.
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
RE: [RFC v2 14/18] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Wed, Jan 09, 2013 at 13:01:03, Shilimkar, Santosh wrote: On Wednesday 09 January 2013 11:08 AM, Bedia, Vaibhav wrote: On Tue, Jan 08, 2013 at 20:51:08, Shilimkar, Santosh wrote: On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: Add minimal APIs for writing to the IPC and the M3_TXEV registers in the Control module. These will be used in a subsequent patch which adds suspend-resume support for AM33XX. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- On Control module, we are trying to move driver/module specific code to respective drivers. Can you not add below code to ipc related driver component. If not, then patch as such is fine with me. I had it in the pm33xx.c in the previous version. Kevin had asked me to move it to control.c. Should I revert move it back there? pm33xx.c is not the right place. I was hoping to move to some driver. If that is not possible then leave it in control module. I think I'll leave it here for now. Could I have you ack in that case? Thanks, Vaibhav -- 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 RESEND] ARM: dts: AM33XX: Rename I2C and GPIO nodes
Hi Benoit, On Jan 8, 2013, at 6:13 PM, Benoit Cousson wrote: Hi Anil, On 01/02/2013 11:12 AM, AnilKumar, Chimata wrote: On Wed, Nov 21, 2012 at 17:22:17, AnilKumar, Chimata wrote: Rename I2C and GPIO nodes according to AM33XX TRM. According to AM33XX TRM device instances are starting from 0 like i2c0, i2c1 and i2c3. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [pa...@antoniou-consulting.com: initial patch by pantelis's] Signed-off-by: AnilKumar Ch anilku...@ti.com --- Changes from first version: - Updated pantelis's patch * Modified based on linux-omap/master * Added GPIO nodes renaming as well Hi Tony/Benoit, If there are no comments could you please pull this patch? Yep, it is done. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.9/dts Regards, Benoit Note that when this lands in mainline, the DT patch bindings for DT overlays must be converted to the correct form. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 14/18] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Wednesday 09 January 2013 03:07 PM, Bedia, Vaibhav wrote: On Wed, Jan 09, 2013 at 13:01:03, Shilimkar, Santosh wrote: On Wednesday 09 January 2013 11:08 AM, Bedia, Vaibhav wrote: On Tue, Jan 08, 2013 at 20:51:08, Shilimkar, Santosh wrote: On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: Add minimal APIs for writing to the IPC and the M3_TXEV registers in the Control module. These will be used in a subsequent patch which adds suspend-resume support for AM33XX. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- On Control module, we are trying to move driver/module specific code to respective drivers. Can you not add below code to ipc related driver component. If not, then patch as such is fine with me. I had it in the pm33xx.c in the previous version. Kevin had asked me to move it to control.c. Should I revert move it back there? pm33xx.c is not the right place. I was hoping to move to some driver. If that is not possible then leave it in control module. I think I'll leave it here for now. Could I have you ack in that case? Yep. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for 3.8] ARM: OMAP: zoom-display: Remove the use of TWL4030_MODULE_PWM1
Use the future proof TWL_MODULE_PWM module id instead to aim the twl-core
cleanup planed for 3.9 kernel cycle.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tony,
can you queue this patch for 3.8 cycle?
With the second part of my twl-core cleanup series I have overlooked this file
since in my working tree I ahve already removed this part of the code and
switched zoom to use the bl-pwm driver for the backlight.
I will resend the series which is doing that on top of this patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82724.html
Thank you,
Peter
arch/arm/mach-omap2/board-zoom-display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
index 1c7c834..8cef477 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -49,13 +49,13 @@ static void zoom_panel_disable_lcd(struct omap_dss_device
*dssdev)
{
}
-/*
- * PWMA/B register offsets (TWL4030_MODULE_PWMA)
- */
+/* Register offsets in TWL4030_MODULE_INTBR */
#define TWL_INTBR_PMBR10xD
#define TWL_INTBR_GPBR10xC
-#define TWL_LED_PWMON 0x0
-#define TWL_LED_PWMOFF 0x1
+
+/* Register offsets in TWL_MODULE_PWM */
+#define TWL_LED_PWMON 0x3
+#define TWL_LED_PWMOFF 0x4
static int zoom_set_bl_intensity(struct omap_dss_device *dssdev, int level)
{
@@ -93,8 +93,8 @@ static int zoom_set_bl_intensity(struct omap_dss_device
*dssdev, int level)
}
c = ((50 * (100 - level)) / 100) + 1;
- twl_i2c_write_u8(TWL4030_MODULE_PWM1, 0x7F, TWL_LED_PWMOFF);
- twl_i2c_write_u8(TWL4030_MODULE_PWM1, c, TWL_LED_PWMON);
+ twl_i2c_write_u8(TWL_MODULE_PWM, 0x7F, TWL_LED_PWMOFF);
+ twl_i2c_write_u8(TWL_MODULE_PWM, c, TWL_LED_PWMON);
#else
pr_warn(Backlight not enabled\n);
#endif
--
1.8.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
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: [PATCH 1/9] mailbox: OMAP: introduce mailbox framework
Hi Loic, On Fri, Dec 21, 2012 at 16:23:24, Loic PALLARDY wrote: On 12/21/2012 11:49 AM, Bedia, Vaibhav wrote: On Fri, Dec 21, 2012 at 14:24:26, Loic PALLARDY wrote: I have a few patches which are dependent on this patch series. Could you please keep me in cc for the future versions. Sure, I'll. When do you plan to post an updated version of these patches? Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
Hi Anil, On 11/14/2012 07:08 PM, AnilKumar Ch wrote: This patch series adds d_can raminit support to c_can/d_can driver, which is required to init/de-init D_CAN message RAM (holds message objects). Added corresponding DT changes to get resource of RAMINIT register and device instance. These patches were tested on AM335x-EVM along with pinctrl data addition patch, which is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1. AnilKumar Ch (3): can: c_can: Add d_can raminit support ARM: dts: AM33XX: Add d_can instances to aliases ARM: dts: AM33XX: Add memory resource to d_can node I've just applied both DTS patches with Acked-by from Marc in my for_3.9/dts branch. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
On Wed, Jan 09, 2013 at 17:46:37, Cousson, Benoit wrote: Hi Anil, On 11/14/2012 07:08 PM, AnilKumar Ch wrote: This patch series adds d_can raminit support to c_can/d_can driver, which is required to init/de-init D_CAN message RAM (holds message objects). Added corresponding DT changes to get resource of RAMINIT register and device instance. These patches were tested on AM335x-EVM along with pinctrl data addition patch, which is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1. AnilKumar Ch (3): can: c_can: Add d_can raminit support ARM: dts: AM33XX: Add d_can instances to aliases ARM: dts: AM33XX: Add memory resource to d_can node I've just applied both DTS patches with Acked-by from Marc in my for_3.9/dts branch. Hi Benoit, Thanks much Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] mailbox: OMAP: introduce mailbox framework
Hi Vaibhav, On 01/09/2013 01:11 PM, Bedia, Vaibhav wrote: Hi Loic, On Fri, Dec 21, 2012 at 16:23:24, Loic PALLARDY wrote: On 12/21/2012 11:49 AM, Bedia, Vaibhav wrote: On Fri, Dec 21, 2012 at 14:24:26, Loic PALLARDY wrote: I have a few patches which are dependent on this patch series. Could you please keep me in cc for the future versions. Sure, I'll. When do you plan to post an updated version of these patches? I'm synchronizing with Omar to include TI RPMsg and tidspbridge patches in next update. So I plan update for end of the week, beginning of next week. Regards, Loic Regards, Vaibhav-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/9] mailbox: OMAP: introduce mailbox framework
On Wed, Jan 09, 2013 at 17:59:39, Loic PALLARDY wrote: Hi Vaibhav, On 01/09/2013 01:11 PM, Bedia, Vaibhav wrote: Hi Loic, On Fri, Dec 21, 2012 at 16:23:24, Loic PALLARDY wrote: On 12/21/2012 11:49 AM, Bedia, Vaibhav wrote: On Fri, Dec 21, 2012 at 14:24:26, Loic PALLARDY wrote: I have a few patches which are dependent on this patch series. Could you please keep me in cc for the future versions. Sure, I'll. When do you plan to post an updated version of these patches? I'm synchronizing with Omar to include TI RPMsg and tidspbridge patches in next update. So I plan update for end of the week, beginning of next week. Ok. Thanks. Regards, Vaibhav -- 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
[PATCH v2 0/5] ARM: OMAP4: Enable AESS IP.
v2: - Add missing AESS memory banks. - Update the serie base on comments related earlier serie: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69853.html The location of the callback has been updated in order to fit with AESS. Some call of PM runtime can be done by ASoC core when AESS is in RET so we need to ensure that the additional callback is call on enable also in order to have clock correctly stop. v1: ARM: OMAP4: Enable AESS IP. This patch serie extends the the hwmod HWMOD_EXT_OPT_MAIN_CLK flag for the AESS IP. This IP has additional register for Auto Gatting configuration. As it is used only for Audio the driver is not always loaded. We can reuse the same flag as McPDM to work around the HW problem due to bad reset value of AESS Auto gatting configuration register. If we try to setup and reset AESS during boot time without this serie the next clocks will still remain enable. omapconf abe cfg: |--| | ABEClock Domain Configuration| ||-| | Clock State Transition control | HW-Auto | | Clock State| | | ABE_24M_FCLK | GATED | | ABE_ALWON_32K_CLK| GATED | | ABE_SYSCLK | GATED | | 24M_FCLK | GATED | | ABE_ICLK2| RUNNING | | DPLL_ABE_X2_CLK | RUNNING | | PAD_CLKS | GATED | | SLIMBUS_CLK | GATED | | OPP Divider| ABE_CLK = DPLL_ABE_X2_CLK/1 | |--| Paul Walmsley (3): ARM: OMAP2+: hwmod: add enable_preprogram hook ASoC: TI AESS: add autogating-enable function, callable from architecture code ARM: OMAP4+: AESS: enable internal auto-gating during initial setup Sebastien Guiriec (2): OMAP4: hwmod data: Enable AESS hwmod device OMAP4: hwmod data: Update AESS data with memory bank area arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/omap_hwmod.c | 18 ++ arch/arm/mach-omap2/omap_hwmod.h |8 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 49 +++-- arch/arm/mach-omap2/omap_hwmod_reset.c | 52 +++ include/sound/aess.h | 53 6 files changed, 178 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_reset.c create mode 100644 include/sound/aess.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
From: Paul Walmsley p...@pwsan.com
Enable the AESS auto-gating control bit during AESS hwmod setup. This
fixes the following boot warning on OMAP4:
omap_hwmod: aess: _wait_target_disable failed
Without this patch, the AESS IP block does not indicate to the PRCM
that it is idle after it is reset. This prevents some types of SoC
power management until something sets the auto-gating control bit.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/omap_hwmod.h |6
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_reset.c | 52
4 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_reset.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 947cafe..d88788f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -8,7 +8,7 @@ obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o
gpmc.o timer.o pm.o \
omap_device.o sram.o
omap-2-3-common= irq.o
-hwmod-common = omap_hwmod.o \
+hwmod-common = omap_hwmod.o omap_hwmod_reset.o \
omap_hwmod_common_data.o
clock-common = clock.o clock_common_data.o \
clkt_dpll.o clkt_clksel.o
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 41066b4..6ec73cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -673,6 +673,12 @@ extern void __init omap_hwmod_init(void);
const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh);
/*
+ *
+ */
+
+extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
+
+/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
*/
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 584acf9..13e397f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -322,6 +322,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_aess_sysc
= {
static struct omap_hwmod_class omap44xx_aess_hwmod_class = {
.name = aess,
.sysc = omap44xx_aess_sysc,
+ .enable_preprogram = omap_hwmod_aess_preprogram,
};
/* aess */
diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c
b/arch/arm/mach-omap2/omap_hwmod_reset.c
new file mode 100644
index 000..bba43fa
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
@@ -0,0 +1,52 @@
+/*
+ * OMAP IP block custom reset and preprogramming stubs
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ * Paul Walmsley
+ *
+ * A small number of IP blocks need custom reset and preprogramming
+ * functions. The stubs in this file provide a standard way for the
+ * hwmod code to call these functions, which are to be located under
+ * drivers/.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+#include linux/kernel.h
+
+#include sound/aess.h
+
+#include omap_hwmod.h
+
+/**
+ * omap_hwmod_aess_preprogram - enable AESS internal autogating
+ * @oh: struct omap_hwmod *
+ *
+ * The AESS will not IdleAck to the PRCM until its internal autogating
+ * is enabled. Since internal autogating is disabled by default after
+ * AESS reset, we must enable autogating after the hwmod code resets
+ * the AESS. Returns 0.
+ */
+int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
+{
+ void __iomem *va;
+
+ va = omap_hwmod_get_mpu_rt_va(oh);
+ if (!va)
+ return -EINVAL;
+
+ aess_enable_autogating(va);
+
+ return 0;
+}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] ARM: OMAP2+: hwmod: add enable_preprogram hook
From: Paul Walmsley p...@pwsan.com
After setup/enable, some IP blocks need some additional setting to
indicate the PRCM that they are inactive until they are configured.
Some examples on OMAP4 include the AESS and FSUSB IP blocks.
To fix this cleanly, this patch adds another optional function
pointer, setup_preprogram, to the IP block's hwmod data. The function
that is pointed to is called by the hwmod code immediately after the
IP block is reset.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 18 ++
arch/arm/mach-omap2/omap_hwmod.h |2 ++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..f37d22c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2053,6 +2053,23 @@ static int _omap4_get_context_lost(struct omap_hwmod *oh)
}
/**
+ * _enable_preprogram - Pre-program an IP block during the _enable() process
+ * @oh: struct omap_hwmod *
+ *
+ * Some IP blocks (such as AESS) require some additional programming
+ * after enable before they can enter idle. If a function pointer to
+ * do so is present in the hwmod data, then call it and pass along the
+ * return value; otherwise, return 0.
+ */
+static int __init _enable_preprogram(struct omap_hwmod *oh)
+{
+ if (!oh-class-enable_preprogram)
+ return 0;
+
+ return oh-class-enable_preprogram(oh);
+}
+
+/**
* _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2156,6 +2173,7 @@ static int _enable(struct omap_hwmod *oh)
_update_sysc_cache(oh);
_enable_sysc(oh);
}
+ r = _enable_preprogram(oh);
} else {
if (soc_ops.disable_module)
soc_ops.disable_module(oh);
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 3ae852a..41066b4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -501,6 +501,7 @@ struct omap_hwmod_omap4_prcm {
* @rev: revision of the IP class
* @pre_shutdown: ptr to fn to be executed immediately prior to device shutdown
* @reset: ptr to fn to be executed in place of the standard hwmod reset fn
+ * @enable_preprogram: ptr to fn to be executed during device enable
*
* Represent the class of a OMAP hardware modules (e.g. timer,
* smartreflex, gpio, uart...)
@@ -524,6 +525,7 @@ struct omap_hwmod_class {
u32 rev;
int (*pre_shutdown)(struct
omap_hwmod *oh);
int (*reset)(struct omap_hwmod *oh);
+ int (*enable_preprogram)(struct
omap_hwmod *oh);
};
/**
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] ASoC: TI AESS: add autogating-enable function, callable from architecture code
From: Paul Walmsley p...@pwsan.com
Add a basic header file for the TI AESS IP block, located in the OMAP4
Audio Back-End subsystem.
Currently, this header file only contains a function to enable the
AESS internal clock auto-gating. This will be used by a subsequent
patch to ensure that the AESS won't block the entire chip
low-power-idle mode. We wish to be able to place the AESS into idle
even when no AESS driver has been compiled in.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Liam Girdwood l...@ti.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
include/sound/aess.h | 53 ++
1 file changed, 53 insertions(+)
create mode 100644 include/sound/aess.h
diff --git a/include/sound/aess.h b/include/sound/aess.h
new file mode 100644
index 000..cee0d09
--- /dev/null
+++ b/include/sound/aess.h
@@ -0,0 +1,53 @@
+/*
+ * AESS IP block reset
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+#ifndef __SOUND_AESS_H__
+#define __SOUND_AESS_H__
+
+#include linux/kernel.h
+#include linux/io.h
+
+/*
+ * AESS_AUTO_GATING_ENABLE_OFFSET: offset in bytes of the AESS IP
+ * block's AESS_AUTO_GATING_ENABLE__1 register from the IP block's
+ * base address
+ */
+#define AESS_AUTO_GATING_ENABLE_OFFSET 0x07c
+
+/* Register bitfields in the AESS_AUTO_GATING_ENABLE__1 register */
+#define AESS_AUTO_GATING_ENABLE_SHIFT 0
+
+/**
+ * aess_enable_autogating - enable AESS internal autogating
+ * @oh: struct omap_hwmod *
+ *
+ * Enable internal autogating on the AESS. This allows the AESS to
+ * indicate that it is idle to the OMAP PRCM. Returns 0.
+ */
+static inline void aess_enable_autogating(void __iomem *base)
+{
+ u32 v;
+
+ /* Set AESS_AUTO_GATING_ENABLE__1.ENABLE to allow idle entry */
+ v = 1 AESS_AUTO_GATING_ENABLE_SHIFT;
+ writel(v, base + AESS_AUTO_GATING_ENABLE_OFFSET);
+}
+
+#endif /* __SOUND_AESS_H__ */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] OMAP4: hwmod data: Enable AESS hwmod device
Enable AESS data in hwmod in order to be able to probe
audio driver.
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 13e397f..6d22fd0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -6279,7 +6279,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l3_main_1__l3_main_3,
omap44xx_l3_main_2__l3_main_3,
omap44xx_l4_cfg__l3_main_3,
- /* omap44xx_aess__l4_abe, */
+ omap44xx_aess__l4_abe,
omap44xx_dsp__l4_abe,
omap44xx_l3_main_1__l4_abe,
omap44xx_mpu__l4_abe,
@@ -6288,8 +6288,8 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_cfg__l4_wkup,
omap44xx_mpu__mpu_private,
omap44xx_l4_cfg__ocp_wp_noc,
- /* omap44xx_l4_abe__aess, */
- /* omap44xx_l4_abe__aess_dma, */
+ omap44xx_l4_abe__aess,
+ omap44xx_l4_abe__aess_dma,
omap44xx_l3_main_2__c2c,
omap44xx_l4_wkup__counter_32k,
omap44xx_l4_cfg__ctrl_module_core,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] OMAP4: hwmod data: Update AESS data with memory bank area
Add AESS memory bank data in hwmod in order to provide memory
address information to the driver.
Signed-off-by: sebastien Guiriec s-guir...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 42
1 file changed, 42 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6d22fd0..631611c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4246,6 +4246,27 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__ocp_wp_noc = {
static struct omap_hwmod_addr_space omap44xx_aess_addrs[] = {
{
+ .name = dmem,
+ .pa_start = 0x4018,
+ .pa_end = 0x4018
+ },
+ {
+ .name = cmem,
+ .pa_start = 0x401a,
+ .pa_end = 0x401a1fff
+ },
+ {
+ .name = smem,
+ .pa_start = 0x401c,
+ .pa_end = 0x401c5fff
+ },
+ {
+ .name = pmem,
+ .pa_start = 0x401e,
+ .pa_end = 0x401e1fff
+ },
+ {
+ .name = mpu,
.pa_start = 0x401f1000,
.pa_end = 0x401f13ff,
.flags = ADDR_TYPE_RT
@@ -4264,6 +4285,27 @@ static struct omap_hwmod_ocp_if __maybe_unused
omap44xx_l4_abe__aess = {
static struct omap_hwmod_addr_space omap44xx_aess_dma_addrs[] = {
{
+ .name = dmem_dma,
+ .pa_start = 0x4908,
+ .pa_end = 0x4908
+ },
+ {
+ .name = cmem_dma,
+ .pa_start = 0x490a,
+ .pa_end = 0x490a1fff
+ },
+ {
+ .name = smem_dma,
+ .pa_start = 0x490c,
+ .pa_end = 0x490c5fff
+ },
+ {
+ .name = pmem_dma,
+ .pa_start = 0x490e,
+ .pa_end = 0x490e1fff
+ },
+ {
+ .name = dma,
.pa_start = 0x490f1000,
.pa_end = 0x490f13ff,
.flags = ADDR_TYPE_RT
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] ARM: OMAP2+: hwmod: add enable_preprogram hook
On Wed, Jan 09, 2013 at 04:03:07PM +0100, Sebastien Guiriec wrote: From: Paul Walmsley p...@pwsan.com After setup/enable, some IP blocks need some additional setting to indicate the PRCM that they are inactive until they are configured. Some examples on OMAP4 include the AESS and FSUSB IP blocks. To fix this cleanly, this patch adds another optional function pointer, setup_preprogram, to the IP block's hwmod data. The function the function pointer is called enable_preprogram. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/5] ASoC: TI AESS: add autogating-enable function, callable from architecture code
On Wed, Jan 09, 2013 at 04:03:08PM +0100, Sebastien Guiriec wrote: From: Paul Walmsley p...@pwsan.com Add a basic header file for the TI AESS IP block, located in the OMAP4 Audio Back-End subsystem. Acked-by: Mark Brown broonie'opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH 05/10] ARM: OMAP2+: PM/powerdomain: move omap_set_pwrdm_state() to powerdomain code
On Wed, Dec 12, 2012 at 03:51:49PM +0530, Vaibhav Hiremath wrote:
-int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst)
-{
- u8 curr_pwrst, next_pwrst;
- int sleep_switch = -1, ret = 0, hwsup = 0;
-
- if (!pwrdm || IS_ERR(pwrdm))
You can use IS_ERR_OR_NULL here.
As this is removing code...
However, if you pay attention to linux-kernel or linux-arm-kernel, you will
notice that I've sent a patch deprecating IS_ERR_OR_NULL() and I'm starting
to remove its use. IS_ERR_OR_NULL() creates more problems than it solves
because people don't think about what the hell they're doing with it, or
even whether it's appropriate to use it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: DT node Timer iteration fix
Hi Pantelis,
On 01/08/2013 07:31 AM, Pantelis Antoniou wrote:
The iterator correctly handles of_node_put() calls.
Remove it before continue'ing the loop.
Without this patch you get:
Thanks for the fix!
May be worth mentioning that this will only be seen with
CONFIG_OF_DYNAMIC (and explains why I did not catch this one!).
ERROR: Bad of_node_put() on /ocp/timer@44e31000!
[c001329c] (unwind_backtrace+0x0/0xe0) from [c03dd8f0]
(of_node_release+0x2c/0xa0)!
[c03dd8f0] (of_node_release+0x2c/0xa0) from [c03ddea0]
(of_find_matching_node_and_match+0x78/0x90)!
[c03ddea0] (of_find_matching_node_and_match+0x78/0x90) from [c06d349c]
(omap_get_timer_dt+0x78/0x90)!
[c06d349c] (omap_get_timer_dt+0x78/0x90) from [c06d3664]
(omap_dm_timer_init_one.clone.2+0x34/0x2bc)!
[c06d3664] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [c06d3a2c]
(omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)!
[c06d3a2c] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from
[c06cca58] (time_init+0x20/0x30)!
[c06cca58] (time_init+0x20/0x30) from [c06c9690]
(start_kernel+0x1a8/0x2fc)!
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/timer.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 691aa67..b8ad6e6 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -165,15 +165,11 @@ static struct device_node * __init
omap_get_timer_dt(struct of_device_id *match,
struct device_node *np;
for_each_matching_node(np, match) {
- if (!of_device_is_available(np)) {
- of_node_put(np);
+ if (!of_device_is_available(np))
continue;
- }
- if (property !of_get_property(np, property, NULL)) {
- of_node_put(np);
+ if (property !of_get_property(np, property, NULL))
continue;
- }
of_add_property(np, device_disabled);
return np;
Otherwise ...
Acked-by: Jon Hunter jon-hun...@ti.com
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: [RFC 0/4] TI LCDC DRM driver
On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark robdcl...@gmail.com wrote: Updated version of DRM driver for TI LCD Controller. Since the initial version of the patch, which only supported TFP410 DVI output, I've added an output driver for LCD panels (for example, LCD3 or LCD7 cape for the beagle-bone), and initial support for HDMI output via NXP TDA19988 HDMI encoder (via i2c encoder-slave output driver). At this point, I think the basic lcdc drm driver plus TFP410 DVI output (first patch) is in reasonable shape (barring potential rename, if lcdc is too generic of a name... but I was not feeling creative enough yet to pick a new name). I'd like at least tilcdc :-) Dave. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] HWMOD fixes for AM33xx PWM submodules and device tree nodes.
Hi Paul, On Wed, Jan 02, 2013 at 18:54:47, Philip, Avinash wrote: This patch series is being part of [1] and resubmitting on top of 3.8-rc1 to make it to 3.9. In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to PWM subsystem. All these submodules shares the resources (clock) has a clock gating register in PWM Subsystem. So a parent PWM subsystem driver is created. To support PWM subsystem driver, parent child relation is created in HWMOD entry in patch #2. In addition EHRPWM module requires explicit clock gating from control module. Hence add clock node for tbclk handling in patch #4. Patch #3 to support common clock migration for AM33xx. Also Device tree nodes populated to support parent child relation between PWMSS, ECAP EHRPWM submodules (patch #5, 6 7). This patch series based on linux_omap/master [2] and tested for backlight with ECAP on AM335x-evm AM335x-evmsk. Are there any reviews on this patch series? This patch set is required for LCD backlight work based on ECAP PWM in am335x-evm am335x-evmsk. Thanks Avinash 1. https://lkml.org/lkml/2012/11/27/120 2. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=c4e2e79ff7c9f4fdad7da432c6b449121cc3033e Philip Avinash (7): ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK ARM: dts: AM33XX: Add PWMSS device tree nodes ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk arch/arm/boot/dts/am335x-evm.dts | 23 ++ arch/arm/boot/dts/am335x-evmsk.dts | 23 ++ arch/arm/boot/dts/am33xx.dtsi | 84 ++ arch/arm/mach-omap2/cclock33xx_data.c | 30 +++ arch/arm/mach-omap2/control.h |8 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 390 ++-- drivers/pwm/pwm-tiehrpwm.c |4 +- 7 files changed, 417 insertions(+), 145 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/7] pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
On Wed, Jan 02, 2013 at 19:08:43, Thierry Reding wrote: On Wed, Jan 02, 2013 at 06:54:50PM +0530, Philip Avinash wrote: The clock framework has changed and it's now better to invoke clock_prepare_enable() and clk_disable_unprepare() rather than the legacy clk_enable() and clk_disable() calls. This patch converts the pwm-tiehrpwm driver to the new framework. Signed-off-by: Philip Avinash avinashphi...@ti.com Cc: Thierry Reding thierry.red...@avionic-design.de --- In 3.8-rc1, common clock frame work support added to AM335x. drivers/pwm/pwm-tiehrpwm.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c index 72a6dd4..af6f162 100644 --- a/drivers/pwm/pwm-tiehrpwm.c +++ b/drivers/pwm/pwm-tiehrpwm.c @@ -341,7 +341,7 @@ static int ehrpwm_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm) configure_polarity(pc, pwm-hwpwm); /* Enable TBCLK before enabling PWM device */ - clk_enable(pc-tbclk); + clk_prepare_enable(pc-tbclk); I apparently didn't catch this before, but maybe it would be useful to check the return value here to make sure we only proceed if the clock can actually be enabled. Ok I will check return value make it return status of pwm_enable(). I will send it as individual patch in next series. I am waiting for reviews / acceptance of HWMOD and clock tree node patches. Thanks Avinash Thierry -- 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 v3 0/3] ARM: dts: omap: add dt data for MUSB
On Friday 28 December 2012 12:05 AM, Aaro Koskinen wrote: Hi, On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include ARM: dts: * Added reg property and interrupt property for usb_otg_hs. Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data Thanks for the update. I've just pulled the series for 3.7. I wonder what happened to the patch #3 (Add usb_otg and glue data) of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. Benoit? -Kishon -- 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: reset handling in am335x hwmod data
Paul == Paul Walmsley p...@pwsan.com writes: Hi Paul, Thanks for the detailed explanaition, and sorry for the slow response - I've been away on holidays. Now the question is why is this configured like this? Paul This behavior is intended to decouple the kernel from the Paul bootloader, or previously-booted operating system (e.g., the Paul kexec case). The original goal was to place the system in an Paul known safe state as soon as possible after the kernel starts. Paul This is to prevent misconfigured or previously-configured devices Paul from trashing memory or chip power management in the Paul currently-booted kernel. It also avoids adding inadvertent Paul bootloader dependencies in driver code. Paul N.B., the plan is to change this behavior over the next few Paul releases. Devices that have drivers associated with them will be Paul reset when the driver loads. Driverless devices will be reset Paul after drivers load, late in boot. Should E.G. the gpio controllers be changed to not reset or should it be configurable in the dts? Paul Probably the DTS is the right place, since this is a board- and Paul bootloader-specific quirk. The original intention was to allow Paul board files to set this HWMOD_INIT_NO_RESET flag themselves - see Paul mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since Paul we've deprecated the board files, the DT data seems like the Paul right place. Paul It probably shouldn't be a GPIO-specific property. Other devices Paul like DSS will also need some kind of 'no-init-reset' property, Paul since on many commercial devices, it's expected that some kind of Paul splash screen will be presented by the bootloader and stay on Paul during the boot process. I tried changing omap_device_build_from_dt() to call omap_hwmod_no_setup_reset() on the corresponding hwmod if a ti,no-init-reset was present, but that doesn't work as the hwmod reset happens quite a bit earlier (in omap_hwmod_setup_all()). Do you have idea how I could work around this or is that the future reset change you referred to above? Paul However, it is probably safest in the long run if you can change Paul the board design to require the SoC to actively reset the FPGA, Paul rather than making reset the default state. That way, if there's Paul some hardware bug that requires the GPIO block to be reset, or if Paul there's some GPIO glitch during power management, the FPGA won't Paul be inadvertently reset. Yes, I'll try to get that done for the next board spin. Thanks! -- Bye, Peter Korsgaard -- 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
