Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct
On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
...
> @@ -55,16 +54,16 @@ static int moxart_gpio_probe(struct platform_device *pdev)
> return ret;
> }
>
> - bgc->gc.label = "moxart-gpio";
> - bgc->gc.request = gpiochip_generic_request;
> - bgc->gc.free = gpiochip_generic_free;
> - bgc->data = bgc->read_reg(bgc->reg_set);
> - bgc->gc.base = 0;
> - bgc->gc.ngpio = 32;
> - bgc->gc.parent = dev;
> - bgc->gc.owner = THIS_MODULE;
> + gc->label = "moxart-gpio";
> + gc->request = gpiochip_generic_request;
> + gc->free = gpiochip_generic_free;
> + gc->bgpio_data = bgc->read_reg(bgc->reg_set);
> + gc->base = 0;
> + gc->ngpio = 32;
> + gc->parent = dev;
> + gc->owner = THIS_MODULE;
>
> - ret = gpiochip_add(>gc);
> + ret = gpiochip_add_data(gc, NULL);
> if (ret) {
gpiochip_add is still mentioned in the dev_err below.
> dev_err(dev, "%s: gpiochip_add failed\n",
> dev->of_node->full_name);
...
> @@ -226,14 +225,14 @@ static int sdv_gpio_probe(struct pci_dev *pdev,
> writel(mux_val, sd->gpio_pub_base + GPMUXCTL);
> }
>
> - ret = bgpio_init(>bgpio, >dev, 4,
> + ret = bgpio_init(>chip, >dev, 4,
> sd->gpio_pub_base + GPINR, sd->gpio_pub_base + GPOUTR,
> NULL, sd->gpio_pub_base + GPOER, NULL, 0);
> if (ret)
> goto unmap;
> - sd->bgpio.gc.ngpio = SDV_NUM_PUB_GPIOS;
> + sd->chip.ngpio = SDV_NUM_PUB_GPIOS;
>
> - ret = gpiochip_add(>bgpio.gc);
> + ret = gpiochip_add_data(>chip, sd);
> if (ret < 0) {
Also still mentioned here in the dev_err.
> dev_err(>dev, "gpiochip_add() failed.\n");
> goto unmap;
...
> @@ -201,8 +201,8 @@ static int vexpress_sysreg_probe(struct platform_device
> *pdev)
> return -ENOMEM;
> bgpio_init(mmc_gpio_chip, >dev, 0x4, base + SYS_MCI,
> NULL, NULL, NULL, NULL, 0);
Was going to complain about this one not switching to _data but it was
addressed in a follow up patch.
> - mmc_gpio_chip->gc.ngpio = 2;
> - gpiochip_add(_gpio_chip->gc);
> + mmc_gpio_chip->ngpio = 2;
> + gpiochip_add(mmc_gpio_chip);
--
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] spi: omap2-mcspi: add runtime PM to set_cs()
On Mon, Aug 31, 2015 at 09:53:55AM +0100, Mark Brown wrote: > On Sun, Aug 30, 2015 at 11:44:45AM -0500, Michael Welling wrote: > > > The patch is currently sitting in linux-next. > > > Not sure why it wasn't merged with 4.2.0-rc8. > > You didn't indicate that it was a bug fix for Linus rather than a fix > for recent development :( Sorry, I did not know that it was my responsibility. How do I indicate this for future reference? The patch that Sebastian sent said the following: " Michael also tested the patch, but have not explicitly written an Tested-By, so you may want to wait for feedback from him. The patch should be sent for 4.2-rc, which introduced the regression. " -- 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] spi: omap2-mcspi: add runtime PM to set_cs()
On Sun, Aug 30, 2015 at 05:45:21PM +0300, Jarkko Nikula wrote: Hi On 07/24/2015 07:39 PM, Mark Brown wrote: On Wed, Jul 22, 2015 at 08:46:09PM +0200, Sebastian Reichel wrote: Since commit ddcad7e9068eb omap2_mcspi_set_cs() is called without runtime power management requested. Thus the below kernel oops may be generated if a device is accessed after the runtime power management timeout. This patch fixes the problem by requesting runtime power management in omap2_mcspi_set_cs(). [ 13.933959] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09802c [ 13.940490] pgd = cfb38000 [ 13.946594] [fa09802c] *pgd=48011452(bad) [ 13.952758] Internal error: : 1028 [#1] PREEMPT ARM [ 13.958862] Modules linked in: tsc2005(+) omap_sham twl4030_wdt omap_wdt [ 13.965332] CPU: 0 PID: 183 Comm: modprobe Not tainted 4.2.0-rc1+ #363 [ 13.971801] Hardware name: Nokia RX-51 board [ 13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000 [ 13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c [ 13.991485] LR is at spi_set_cs+0x5c/0x60 Please don't paste entire backtraces into commit messages, they are very large and almost entirely noise (for example in this case the entire explanation is in the commit message itself). If you feel a backtrace helps clarify things then please present an *edited* highlight of the relevant sections. present Is there update to this patch? I don't see such in 4.2.0-rc8+. I hit this same issue on Nokia N900 WLAN (CONFIG_WL1251=m and CONFIG_WL1251_SPI=m) and googling lead to this patch which made the WLAN working. If you are going to resend this, please feel free to add my tested by: Tested-by: Jarkko Nikula jarkko.nik...@bitmer.com The patch is currently sitting in linux-next. Not sure why it wasn't merged with 4.2.0-rc8. -- 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] spi: omap2-mcspi: add runtime PM to set_cs()
:
https://lkml.org/lkml/2015/7/11/98
Michael also tested the patch, but have not explicitly written an
Tested-By, so you may want to wait for feedback from him. The patch
should be sent for 4.2-rc, which introduced the regression.
-- Sebastian
---
drivers/spi/spi-omap2-mcspi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5867384..3d09e0b 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
u32 l;
/* The controller handles the inverted chip selects
@@ -255,6 +256,12 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
bool enable)
enable = !enable;
if (spi-controller_state) {
+ int err = pm_runtime_get_sync(mcspi-dev);
+ if (err 0) {
+ dev_err(mcspi-dev, failed to get sync: %d\n, err);
+ return;
+ }
+
Acked-by: Michael Welling mwell...@ieee.org
l = mcspi_cached_chconf0(spi);
if (enable)
@@ -263,6 +270,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
bool enable)
l |= OMAP2_MCSPI_CHCONF_FORCE;
mcspi_write_chconf0(spi, l);
+
+ pm_runtime_mark_last_busy(mcspi-dev);
+ pm_runtime_put_autosuspend(mcspi-dev);
}
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
On Wed, Jul 22, 2015 at 04:03:07AM +0200, Sebastian Reichel wrote:
Hi,
On Tue, Jul 21, 2015 at 07:17:41PM -0500, Michael Welling wrote:
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into the
kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your side.
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index cf8b91b..3164d13 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
if (!spi-max_speed_hz)
spi-max_speed_hz = spi-master-max_speed_hz;
- spi_set_cs(spi, false);
-
if (spi-master-setup)
status = spi-master-setup(spi);
+ spi_set_cs(spi, false);
+
dev_dbg(spi-dev, setup mode %d, %s%s%s%s%u bits/w, %u Hz max --
%d\n,
(int) (spi-mode (SPI_CPOL | SPI_CPHA)),
(spi-mode SPI_CS_HIGH) ? cs_high, : ,
mh. maybe a runtime PM issue?
mh?
* external abort on non-linefetch: address cannot be accessed,
since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit
faster (module must not be loaded from filesystem), so that
the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup
routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a
prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to
suspend after the runtime PM acquisition in setup()
So I suggest trying the following (compile tested only) patch:
It seems you are right.
With this patch the SPI drivers no longer cause data aborts.
I will wait for feedback from Pavel and Pali but it looks like
we have a winner.
-- Sebastian
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5867384..f7d9ffd 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
u32 l;
/* The controller handles the inverted chip selects
@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
bool enable)
enable = !enable;
if (spi-controller_state) {
+ pm_runtime_get_sync(mcspi-dev);
+
Should the return code should be checked here as with the other
instances of pm_runtime_get_sync?
l = mcspi_cached_chconf0(spi);
if (enable)
@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
bool enable)
l |= OMAP2_MCSPI_CHCONF_FORCE;
mcspi_write_chconf0(spi, l);
+
+ pm_runtime_mark_last_busy(mcspi-dev);
+ pm_runtime_put_autosuspend(mcspi-dev);
}
}
--
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: linux 4.2-rc1 broken Nokia N900
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote: Actually.. for the record I'm _not_ using modules. So either I hit something different, or problem happens regardless of modules. Pavel I was able to reproduce the error by using my Beagleboard. I added a registration for the tsc2005 and built the driver as a module. [4.318878] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09802c [4.326934] pgd = cf114000 [4.329742] [fa09802c] *pgd=48011452(bad) [4.333953] Internal error: : 1028 [#1] PREEMPT ARM [4.339050] Modules linked in: tsc2005(+) twl4030_wdt(+) rtc_twl(+) omap_ssi hsi [4.346832] CPU: 0 PID: 74 Comm: udevd Not tainted 4.2.0-rc3+ #2 [4.353118] Hardware name: Generic OMAP3-GP (Flattened Device Tree) [4.359680] task: cf0a8f00 ti: cf112000 task.ti: cf112000 [4.365356] PC is at omap2_mcspi_set_cs+0x3c/0x44 [4.370269] LR is at spi_setup+0xd4/0x10c [4.374450] pc : [c0328b5c]lr : [c0326a6c]psr: 200f0113 [4.374450] sp : cf113d48 ip : 0001 fp : 0fff [4.386474] r10: cf31ffe4 r9 : r8 : 0008 [4.391937] r7 : 0fff r6 : r5 : r4 : cfbdbe00 [4.398773] r3 : 200103dc r2 : fa098000 r1 : 0001 r0 : cfbdbe00 [4.405578] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [4.413055] Control: 10c5387d Table: 8f114019 DAC: 0015 [4.419067] Process udevd (pid: 74, stack limit = 0xcf112210) [4.425079] Stack: (0xcf113d48 to 0xcf114000) [4.429626] 3d40: cfbdbe00 cfbdbe00 cfce7ab8 bf017ac8 cfbdd5a0 c015dc08 [4.438201] 3d60: cf352190 0fff 0004 0008 0002 0118 1f40 [4.446746] 3d80: 0001 bf0183cc cfbdbe00 bf0183dc 0008 0001 cf31ffe4 [4.455322] 3da0: cf31ffc8 c0326458 c0326408 cfbdbe00 c073e81c c02e7ca0 cfbdbe00 cfbdbe34 [4.463867] 3dc0: bf0183dc c06e8254 c06aefe0 c02e7e6c bf0183dc c02e7e04 c02e6530 [4.472442] 3de0: cf964c4c cfbd89b0 bf0183dc cf322200 c02e74e8 bf01830f bf018310 [4.480987] 3e00: bf0183dc bf01a000 c06aefe0 c02e8904 cf353080 [4.489562] 3e20: bf01a000 c0009640 cf978000 0001 0001 [4.498107] 3e40: cf07c008 00150013 cf07c000 600f0113 c06db824 c06db824 cfedf9c0 0040003f [4.506683] 3e60: cfedf9c0 00150013 cfcf9000 0008 cf801f00 00d0 bf018440 bf018440 [4.515228] 3e80: 0001 cf353040 bf018488 cf31ffc0 0001 c046c4b8 bf018440 c06ffb90 [4.523803] 3ea0: cf113f58 0001 bf018440 c00875b0 bf01844c 7fff c0084f8c [4.532348] 3ec0: c0084b28 bf018614 bf018640 00026d29 d09c503c b6f0aec0 c0084c60 [4.540924] 3ee0: d09a8000 00026d29 03e9 0b32 [4.549468] 3f00: [4.558044] 3f20: 0138 b6f0aec0 0005 [4.566589] 3f40: 017b c000ebc4 cf112000 bef58e70 c0087bec d09a8000 00026d29 [4.575134] 3f60: d09c4934 d09c4764 d09ce71c 1640 19e0 [4.583709] 3f80: 002d 002e 0017 0014 0012 0004a898 [4.592254] 3fa0: c000ea40 0004a898 0005 b6f0aec0 0002 [4.600830] 3fc0: 0004a898 017b 0004a898 0004aa30 bef58e70 [4.609374] 3fe0: bef58d98 bef58d88 b6f0399c b6e93ed0 60070010 0005 [4.617950] [c0328b5c] (omap2_mcspi_set_cs) from [c0326a6c] (spi_setup+0xd4/0x10c) [4.626281] [c0326a6c] (spi_setup) from [bf017ac8] (tsc2005_probe+0x108/0x5d4 [tsc2005]) [4.635131] [bf017ac8] (tsc2005_probe [tsc2005]) from [c0326458] (spi_drv_probe+0x50/0x6c) [4.644165] [c0326458] (spi_drv_probe) from [c02e7ca0] (driver_probe_device+0xf4/0x258) [4.652893] [c02e7ca0] (driver_probe_device) from [c02e7e6c] (__driver_attach+0x68/0x8c) [4.661743] [c02e7e6c] (__driver_attach) from [c02e6530] (bus_for_each_dev+0x6c/0x90) [4.670318] [c02e6530] (bus_for_each_dev) from [c02e74e8] (bus_add_driver+0xcc/0x1e4) [4.678863] [c02e74e8] (bus_add_driver) from [c02e8904] (driver_register+0x9c/0xe0) [4.687255] [c02e8904] (driver_register) from [c0009640] (do_one_initcall+0x100/0x1b0) [4.695922] [c0009640] (do_one_initcall) from [c046c4b8] (do_init_module+0x58/0x1c0) [4.704406] [c046c4b8] (do_init_module) from [c00875b0] (load_module+0x16ac/0x1b64) [4.712799] [c00875b0] (load_module) from [c0087bec] (SyS_finit_module+0x60/0x68) [4.721008] [c0087bec] (SyS_finit_module) from [c000ea40] (ret_fast_syscall+0x0/0x3c) [4.729553] Code: e5823018 e5902188 e5922000 e582302c (e592302c) [4.735961] ---[ end trace 375298308353557f ]--- Now to figure out why this is
Re: linux 4.2-rc1 broken Nokia N900
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote: This code has my head spinning. I found that the errors do not occur when the driver is built into the kernel. I also found that with the patch below the errors go away. Not sure if it is acceptible but see if it fixes things on your side. diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index cf8b91b..3164d13 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi) if (!spi-max_speed_hz) spi-max_speed_hz = spi-master-max_speed_hz; - spi_set_cs(spi, false); - if (spi-master-setup) status = spi-master-setup(spi); + spi_set_cs(spi, false); + dev_dbg(spi-dev, setup mode %d, %s%s%s%s%u bits/w, %u Hz max -- %d\n, (int) (spi-mode (SPI_CPOL | SPI_CPHA)), (spi-mode SPI_CS_HIGH) ? cs_high, : , -- 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: linux 4.2-rc1 broken Nokia N900
On Tue, Jul 14, 2015 at 09:14:12AM +0200, Pali Rohár wrote: On Monday 13 July 2015 17:36:07 Michael Welling wrote: On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote: I think nothing special. I just call: export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- make rx51_defconfig rm -f arch/arm/boot/zImage make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage Where are you getting rx51_defconfig from? This does not appear to be in the kernel source any longer. Can you try the above with omap2plus_defconfig? It is in my linux-n900 repository: https://github.com/pali/linux-n900 Repository contains more n900 specific patches but SPI code is unpatched https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration. Has any progress been made on this? Seeing as I was dropped into the middle of this thread, I took a look at the discussion previous. It appears that you are building the drivers as modules. Perhaps I can again attempt to duplicate the issue using modules. Though this should not make a difference. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
On Wed, Jul 15, 2015 at 09:49:33PM +0200, Pavel Machek wrote: Hi! Ok, so: 4.2-rc1 worked for me, IIRC. This does not make sense. Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you? Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place. 4.2-rc2 oopses a lot. 4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops. But... I'm not sure I'm getting the same oops. Pavel Any progress as to what is causing the oops for you starting at 4.2-rc2? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
On Wed, Jul 15, 2015 at 09:49:33PM +0200, Pavel Machek wrote: Hi! Ok, so: 4.2-rc1 worked for me, IIRC. This does not make sense. Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you? Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place. Interesting. Something very strange is happening here. Send me the links if you push your tree/config to a public repo. I would not hurt to have the same from Pali for comparison. 4.2-rc2 oopses a lot. 4.2-rc2+ this patch oopses, too. I don't have serial console, so it is hard to tell if it is the same oops. But... I'm not sure I'm getting the same oops. If the system is still booting, you could tell if the oopses were the same if your touchscreen and wifi do no work. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
On Tue, Jul 14, 2015 at 09:14:12AM +0200, Pali Rohár wrote:
On Monday 13 July 2015 17:36:07 Michael Welling wrote:
On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote:
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y
cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb
arch/arm/boot/zImage.new
mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?
It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
Later in week I can try to compile also with omap2plus_defconfig...
But in my opinion kernel should not crash with different configuration.
True.
Could you try the following change to the set_cs function and see if it helps.
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5867384..666038b 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,16 +245,18 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi_cs *cs = spi-controller_state;
u32 l;
- /* The controller handles the inverted chip selects
-* using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
-* the inversion from the core spi_set_cs function.
-*/
- if (spi-mode SPI_CS_HIGH)
- enable = !enable;
+ if (cs) {
+
+ /* The controller handles the inverted chip selects
+* using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
+* the inversion from the core spi_set_cs function.
+*/
+ if (spi-mode SPI_CS_HIGH)
+ enable = !enable;
- if (spi-controller_state) {
l = mcspi_cached_chconf0(spi);
if (enable)
--
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: linux 4.2-rc1 broken Nokia N900
On Tue, Jul 14, 2015 at 10:01:26PM +0200, Pavel Machek wrote:
On Tue 2015-07-14 11:33:42, Michael Welling wrote:
On Tue, Jul 14, 2015 at 09:14:12AM +0200, Pali Rohár wrote:
On Monday 13 July 2015 17:36:07 Michael Welling wrote:
On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote:
I think nothing special. I just call:
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make rx51_defconfig
rm -f arch/arm/boot/zImage
make -j12 zImage modules omap3-n900.dtb
CONFIG_DEBUG_SECTION_MISMATCH=y
cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb
arch/arm/boot/zImage.new
mv arch/arm/boot/zImage.new arch/arm/boot/zImage
Where are you getting rx51_defconfig from?
This does not appear to be in the kernel source any longer.
Can you try the above with omap2plus_defconfig?
It is in my linux-n900 repository: https://github.com/pali/linux-n900
Repository contains more n900 specific patches but SPI code is unpatched
https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
Later in week I can try to compile also with omap2plus_defconfig...
But in my opinion kernel should not crash with different configuration.
True.
Could you try the following change to the set_cs function and see if
it helps.
Ok, so:
4.2-rc1 worked for me, IIRC.
This does not make sense.
Nothing has changed in drivers/spi between these versions.
Are you sure that 4.2-rc1 worked for you?
4.2-rc2 oopses a lot.
4.2-rc2+ this patch oopses, too. I don't have serial console, so it is
hard to tell if it is the same oops.
Pavel
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5867384..666038b 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,16 +245,18 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi_cs *cs = spi-controller_state;
u32 l;
- /* The controller handles the inverted chip selects
-* using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
-* the inversion from the core spi_set_cs function.
-*/
- if (spi-mode SPI_CS_HIGH)
- enable = !enable;
+ if (cs) {
+
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
On Mon, Jul 13, 2015 at 07:09:06PM +0200, Pali Rohár wrote: On Monday 13 July 2015 19:03:44 Michael Welling wrote: On Mon, Jul 13, 2015 at 10:09:21AM +0200, Sebastian Reichel wrote: [+cc Michael Welling mwell...@ieee.org, author of all omap-spi patches between 4.1 and 4.2-rc1] Hi, On Sun, Jul 12, 2015 at 11:44:25PM -0700, Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150711 05:07]: Hello, now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops... Basically wifi, touchscreen and rtc drivers not working... Here are some relevant snippets form dmesg: [ 13.933959] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09802c [ 13.940490] pgd = cfb38000 [ 13.946594] [fa09802c] *pgd=48011452(bad) [ 13.952758] Internal error: : 1028 [#1] PREEMPT ARM [ 13.958862] Modules linked in: tsc2005(+) omap_sham twl4030_wdt omap_wdt [ 13.965332] CPU: 0 PID: 183 Comm: modprobe Not tainted 4.2.0-rc1+ #363 [ 13.971801] Hardware name: Nokia RX-51 board [ 13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000 [ 13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c Here is the disassembly of the omap2_mcspi_set_cs function from my compiler: 0040 omap2_mcspi_set_cs: 40: e2803e25add r3, r0, #592; 0x250 44: e5902258ldr r2, [r0, #600] ; 0x258 48: e1d330b2ldrhr3, [r3, #2] 4c: e3130004tst r3, #4 50: 12211001eorne r1, r1, #1 54: e352cmp r2, #0 58: 012fff1ebxeqlr 5c: e5923018ldr r3, [r2, #24] 60: e351cmp r1, #0 64: 13c33601bicne r3, r3, #1048576; 0x10 68: 03833601orreq r3, r3, #1048576; 0x10 6c: e5823018str r3, [r2, #24] 70: e5902258ldr r2, [r0, #600] ; 0x258 74: e5922000ldr r2, [r2] 78: e582302cstr r3, [r2, #44] ; 0x2c 7c: e5903258ldr r3, [r0, #600] ; 0x258 80: e5933000ldr r3, [r3] 84: e593202cldr r2, [r3, #44] ; 0x2c 88: e12fff1ebx lr The omap2_mcspi_set_cs function is being called before the controller_state is initialized in omap2_mcspi_setup. That is why there is a conditional checking if controller_state is NULL. Perhaps the controller_state is uninitialized but has garbage instead of NULL causing the data abort. Though that does not make much sense because a similar check in the setup function did not cause a data abort in the past. Not sure what is going wrong here. Could you do a objdump with the compiler you are using? Hello, here is my objdump of 4.2-rc2 version: 0064 omap2_mcspi_set_cs: 64: e3003182movwr3, #386; 0x182 68: e19030b3ldrhr3, [r0, r3] 6c: e3130004tst r3, #4 70: 0a01beq 7c omap2_mcspi_set_cs+0x18 74: e2711001rsbsr1, r1, #1 78: 33a01000movcc r1, #0 7c: e5902188ldr r2, [r0, #392] ; 0x188 80: e352cmp r2, #0 84: 012fff1ebxeqlr 88: e5923018ldr r3, [r2, #24] 8c: e351cmp r1, #0 90: 13c33601bicne r3, r3, #1048576; 0x10 94: 03833601orreq r3, r3, #1048576; 0x10 98: e5823018str r3, [r2, #24] 9c: e5902188ldr r2, [r0, #392] ; 0x188 a0: e5922000ldr r2, [r2] a4: e582302cstr r3, [r2, #44] ; 0x2c a8: e592302cldr r3, [r2, #44] ; 0x2c ac: e12fff1ebx lr 0x64+0x44 = 0xa8 That means that it got past the check for controller_state being NULL. So that means that controller_state is not NULL and not initialized properly causing the data abort. It still does not explain how the driver used to work given it initializes the controller_state in the setup function after doing the same check. Let me dig a little more. Wish I had a N900 to try this on. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
On Mon, Jul 13, 2015 at 10:09:21AM +0200, Sebastian Reichel wrote:
[+cc Michael Welling mwell...@ieee.org, author of all omap-spi patches
between 4.1 and 4.2-rc1]
Hi,
On Sun, Jul 12, 2015 at 11:44:25PM -0700, Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150711 05:07]:
Hello,
now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are
broken and cause kernel oops...
Basically wifi, touchscreen and rtc drivers not working...
Here are some relevant snippets form dmesg:
[ 13.933959] Unhandled fault: external abort on non-linefetch (0x1028)
at 0xfa09802c
[ 13.940490] pgd = cfb38000
[ 13.946594] [fa09802c] *pgd=48011452(bad)
[ 13.952758] Internal error: : 1028 [#1] PREEMPT ARM
[ 13.958862] Modules linked in: tsc2005(+) omap_sham twl4030_wdt
omap_wdt
[ 13.965332] CPU: 0 PID: 183 Comm: modprobe Not tainted 4.2.0-rc1+ #363
[ 13.971801] Hardware name: Nokia RX-51 board
[ 13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000
[ 13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c
Here is the disassembly of the omap2_mcspi_set_cs function from my compiler:
0040 omap2_mcspi_set_cs:
40: e2803e25add r3, r0, #592; 0x250
44: e5902258ldr r2, [r0, #600] ; 0x258
48: e1d330b2ldrhr3, [r3, #2]
4c: e3130004tst r3, #4
50: 12211001eorne r1, r1, #1
54: e352cmp r2, #0
58: 012fff1ebxeqlr
5c: e5923018ldr r3, [r2, #24]
60: e351cmp r1, #0
64: 13c33601bicne r3, r3, #1048576; 0x10
68: 03833601orreq r3, r3, #1048576; 0x10
6c: e5823018str r3, [r2, #24]
70: e5902258ldr r2, [r0, #600] ; 0x258
74: e5922000ldr r2, [r2]
78: e582302cstr r3, [r2, #44] ; 0x2c
7c: e5903258ldr r3, [r0, #600] ; 0x258
80: e5933000ldr r3, [r3]
84: e593202cldr r2, [r3, #44] ; 0x2c
88: e12fff1ebx lr
The omap2_mcspi_set_cs function is being called before the controller_state is
initialized in omap2_mcspi_setup.
That is why there is a conditional checking if controller_state is NULL.
Perhaps the controller_state is uninitialized but has garbage instead of NULL
causing the data abort.
Though that does not make much sense because a similar check in the setup
function
did not cause a data abort in the past.
Not sure what is going wrong here.
Could you do a objdump with the compiler you are using?
[ 13.991485] LR is at spi_set_cs+0x5c/0x60
[ 13.997985] pc : [c02bd3ac]lr : [c02baecc]psr: 2013
[ 13.997985] sp : cb1f3dd0 ip : 0001 fp : 0004
[ 14.011260] r10: cfce5be8 r9 : 0fff r8 : c0654f98
[ 14.017913] r7 : r6 : r5 : r4 :
[ 14.024505] r3 : 200103dc r2 : fa098000 r1 : 0001 r0 : cf09bc00
[ 14.031036] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 14.037689] Control: 10c5387d Table: 8fb38019 DAC: 0015
[ 14.044403] Process modprobe (pid: 183, stack limit = 0xcb1f2210)
[ 14.051300] Stack: (0xcb1f3dd0 to 0xcb1f4000)
[ 14.058105] 3dc0: cf09bc00
c02bafa4 cf09bc00 cf09bc00
[ 14.065277] 3de0: bf013444 bf01254c cf0e2230 cf0e2230 0001
c0654f98 0fff 0fff
[ 14.072570] 3e00: 0008 0002 0118 1f40 0031
cf09bc00 ffed bf013444
[ 14.080078] 3e20: 0031 c0654f98 cb1f2000
c02bb5c0 cf09bc00
[ 14.087738] 3e40: bf013454 c027a2f4 cf09bc00 bf013454
bf013454 c027a594
[ 14.095367] 3e60: cf09bc00 cf09bc34 c027a60c bf013454
cb1f3e80 c027a5ac c0278ec8
[ 14.102935] 3e80: cf972c4c cf09d630 bf013454 bf013454 cbb55300
c06848d8 c0279c84
[ 14.110473] 3ea0: bf01327c bf01327d bf013454 cb889180
c0654f98 c027b0c8
[ 14.117980] 3ec0: bf015000 cb889180 c00095b0 0040003e
cfe6a080 0040003f
[ 14.125457] 3ee0: 0008 cfcf9000 cb1f2000 6013 0040003e
cbf1bbc0 0001
[ 14.132843] 3f00: bf0134cc cb1f2000 bf0134c0 cb1f3f58
c04352d0 cf801f00 00d0
[ 14.140136] 3f20: bf0134c0 bf0134c0 416c cb889040 0080
c000ebe4 cb1f2000 c0089f68
[ 14.147308] 3f40: bf0134c0 cbf1bc00 001a9193 416c 001f8d20
c008ab30 d0b1 416c
[ 14.154571] 3f60: d0b1267c d0b1252b d0b13514 16c0 1ad0
[ 14.161865] 3f80: 001f 0020 0017 0014 0012
00201208
[ 14.169097] 3fa0:
Re: linux 4.2-rc1 broken Nokia N900
On Mon, Jul 13, 2015 at 07:09:06PM +0200, Pali Rohár wrote: Hello, here is my objdump of 4.2-rc2 version: 0064 omap2_mcspi_set_cs: 64: e3003182movwr3, #386; 0x182 68: e19030b3ldrhr3, [r0, r3] 6c: e3130004tst r3, #4 70: 0a01beq 7c omap2_mcspi_set_cs+0x18 74: e2711001rsbsr1, r1, #1 78: 33a01000movcc r1, #0 7c: e5902188ldr r2, [r0, #392] ; 0x188 80: e352cmp r2, #0 84: 012fff1ebxeqlr 88: e5923018ldr r3, [r2, #24] 8c: e351cmp r1, #0 90: 13c33601bicne r3, r3, #1048576; 0x10 94: 03833601orreq r3, r3, #1048576; 0x10 98: e5823018str r3, [r2, #24] 9c: e5902188ldr r2, [r0, #392] ; 0x188 a0: e5922000ldr r2, [r2] a4: e582302cstr r3, [r2, #44] ; 0x2c a8: e592302cldr r3, [r2, #44] ; 0x2c ac: e12fff1ebx lr I have not been able to duplicate the failure on the hardware that I have. I dug out my old Beagleboard and added an SPI registration to the dts. This was the closest hardware that I had to the N900's processor. What is the version of the gcc compiler you are using and where did you get it from? For instance, I am using a 4.9.1 compiler that I built using Yocto. Also are you using devicetree or the old board file board-rx51.c? -- 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: linux 4.2-rc1 broken Nokia N900
On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote: I think nothing special. I just call: export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- make rx51_defconfig rm -f arch/arm/boot/zImage make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage Where are you getting rx51_defconfig from? This does not appear to be in the kernel source any longer. Can you try the above with omap2plus_defconfig? -- 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: linux 4.2-rc1 broken Nokia N900
On Mon, Jul 13, 2015 at 10:34:21PM +0200, Pali Rohár wrote: On Monday 13 July 2015 22:28:35 Michael Welling wrote: On Mon, Jul 13, 2015 at 07:09:06PM +0200, Pali Rohár wrote: Hello, here is my objdump of 4.2-rc2 version: 0064 omap2_mcspi_set_cs: 64: e3003182movwr3, #386; 0x182 68: e19030b3ldrhr3, [r0, r3] 6c: e3130004tst r3, #4 70: 0a01beq 7c omap2_mcspi_set_cs+0x18 74: e2711001rsbs r1, r1, #1 78: 33a01000movcc r1, #0 7c: e5902188ldr r2, [r0, #392] ; 0x188 80: e352cmp r2, #0 84: 012fff1ebxeqlr 88: e5923018ldr r3, [r2, #24] 8c: e351cmp r1, #0 90: 13c33601bicne r3, r3, #1048576; 0x10 94: 03833601orreq r3, r3, #1048576 ; 0x10 98: e5823018str r3, [r2, #24] 9c: e5902188ldr r2, [r0, #392] ; 0x188 a0: e5922000ldr r2, [r2] a4: e582302cstr r3, [r2, #44] ; 0x2c a8: e592302cldr r3, [r2, #44] ; 0x2c ac: e12fff1ebx lr I have not been able to duplicate the failure on the hardware that I have. I dug out my old Beagleboard and added an SPI registration to the dts. This was the closest hardware that I had to the N900's processor. What is the version of the gcc compiler you are using and where did you get it from? I'm using gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) from package gcc-4.6-arm-linux-gnueabi which is available on Ubuntu 12.04 LTS (version 4.6.3-1ubuntu5cross1.62). I downloaded and compiled with this compiler and it still does not effect the functionality of the targets that I have. What flags (if any) are you passing to the compiler? Here is my objdump with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5): 0074 omap2_mcspi_set_cs: 74: e59f304cldr r3, [pc, #76] ; c8 omap2_mcspi_set_cs+0x54 78: e19030b3ldrhr3, [r0, r3] 7c: e3130004tst r3, #4 80: 0a01beq 8c omap2_mcspi_set_cs+0x18 84: e2711001rsbsr1, r1, #1 88: 33a01000movcc r1, #0 8c: e5903258ldr r3, [r0, #600] ; 0x258 90: e353cmp r3, #0 94: 012fff1ebxeqlr 98: e5932018ldr r2, [r3, #24] 9c: e351cmp r1, #0 a0: 13c22601bicne r2, r2, #1048576; 0x10 a4: 03822601orreq r2, r2, #1048576; 0x10 a8: e5832018str r2, [r3, #24] ac: e5903258ldr r3, [r0, #600] ; 0x258 b0: e5933000ldr r3, [r3] b4: e583202cstr r2, [r3, #44] ; 0x2c b8: e5903258ldr r3, [r0, #600] ; 0x258 bc: e5933000ldr r3, [r3] c0: e593202cldr r2, [r3, #44] ; 0x2c c4: e12fff1ebx lr c8: 0252.word 0x0252 For instance, I am using a 4.9.1 compiler that I built using Yocto. Also are you using devicetree or the old board file board-rx51.c? I'm using devicetree. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] spi: omap2-mcspi: Handle error on gpio_request
On Sun, May 24, 2015 at 10:13:07AM +0200, Nicholas Mc Guire wrote:
On Sat, 23 May 2015, Michael Welling wrote:
If a valid GPIO is specified but cannot be requested by the driver, print a
message and error out of omap2_mcspi_setup.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index c4e21ad..5867384 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1023,9 +1023,12 @@ static int omap2_mcspi_setup(struct spi_device *spi)
}
if (gpio_is_valid(spi-cs_gpio)) {
- if (gpio_request(spi-cs_gpio, dev_name(spi-dev)) == 0)
- gpio_direction_output(spi-cs_gpio,
- !(spi-mode SPI_CS_HIGH));
+ ret = gpio_request(spi-cs_gpio, dev_name(spi-dev));
+ if (ret) {
+ dev_err(spi-dev, failed to request gpio\n);
+ return ret;
+ }
+ gpio_direction_output(spi-cs_gpio, !(spi-mode SPI_CS_HIGH));
}
just wondering if the outer gpio_is_valid is actually needed as it seems
gpio_request() is actually calling gpio_is_valid() anyway and would return
non 0 if it were not,
In this case we have to check first because if the GPIO is not registered the
native chip select is assumed. If the GPIO is registered, is valid and can be
requested we use it as the chip select. If the GPIO is registered and valid but
cannot be requested we return an error.
thx!
hofrat
--
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/4] spi: omap2-mcspi: Fix set_cs function for active high
The core spi driver swaps the polarity of the enable based on SPI_CS_HIGH.
The omap2 controller has an internal configuration register bit called
OMAP2_MCSPI_CHCONF_EPOL to handle active high chip selects as well.
So we have to revert swap the polarity back for the correct setting of the
OMAP2_MCSPI_CHCONF_FORCE bit in omap2_mcspi_set_cs.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 304b427..502db29 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -247,6 +247,13 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
bool enable)
{
u32 l;
+ /* The controller handles the inverted chip selects
+* using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
+* the inversion from the core spi_set_cs function.
+*/
+ if (spi-mode SPI_CS_HIGH)
+ enable = !enable;
+
if (spi-controller_state) {
l = mcspi_cached_chconf0(spi);
--
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 0/4] spi: omap2-mcspi: Fixes for recent updates
The recent update of the OMAP2 McSPI driver left some unresolved issues. These patches should take care them and again allow for GPIO chip selects and native chip selects. Michael Welling (4): spi: omap2-mcspi: Remove unnecessary delay spi: omap2-mcspi: Fix set_cs function for active high spi: omap2-mcspi: Fix GPIO chip select support spi: omap2-mcspi: Handle error on gpio_request drivers/spi/spi-omap2-mcspi.c | 25 +++-- 1 file changed, 19 insertions(+), 6 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
[PATCH 3/4] spi: omap2-mcspi: Fix GPIO chip select support
The OMAP2_MCSPI_CHCONF_FORCE must be toggled even when using GPIO
chip selects. This patch conditionally calls the omap2_mcspi_set_cs
function to do so when using GPIO chip selects.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 502db29..c4e21ad 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1108,6 +1108,9 @@ static int omap2_mcspi_work_one(struct omap2_mcspi *mcspi,
omap2_mcspi_set_enable(spi, 0);
+ if (gpio_is_valid(spi-cs_gpio))
+ omap2_mcspi_set_cs(spi, spi-mode SPI_CS_HIGH);
+
if (par_override ||
(t-speed_hz != spi-max_speed_hz) ||
(t-bits_per_word != spi-bits_per_word)) {
@@ -1192,6 +1195,9 @@ out:
omap2_mcspi_set_enable(spi, 0);
+ if (gpio_is_valid(spi-cs_gpio))
+ omap2_mcspi_set_cs(spi, !(spi-mode SPI_CS_HIGH));
+
if (mcspi-fifo_depth 0 t)
omap2_mcspi_set_fifo(spi, t, 0);
--
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 4/4] spi: omap2-mcspi: Handle error on gpio_request
If a valid GPIO is specified but cannot be requested by the driver, print a
message and error out of omap2_mcspi_setup.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index c4e21ad..5867384 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1023,9 +1023,12 @@ static int omap2_mcspi_setup(struct spi_device *spi)
}
if (gpio_is_valid(spi-cs_gpio)) {
- if (gpio_request(spi-cs_gpio, dev_name(spi-dev)) == 0)
- gpio_direction_output(spi-cs_gpio,
- !(spi-mode SPI_CS_HIGH));
+ ret = gpio_request(spi-cs_gpio, dev_name(spi-dev));
+ if (ret) {
+ dev_err(spi-dev, failed to request gpio\n);
+ return ret;
+ }
+ gpio_direction_output(spi-cs_gpio, !(spi-mode SPI_CS_HIGH));
}
ret = pm_runtime_get_sync(mcspi-dev);
--
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 1/4] spi: omap2-mcspi: Remove unnecessary delay
The core spi driver handles the delay between transactions. This is a remanant from the transfer_one conversion. Signed-off-by: Michael Welling mwell...@ieee.org --- drivers/spi/spi-omap2-mcspi.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index a7d85c5..304b427 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -1163,9 +1163,6 @@ static int omap2_mcspi_work_one(struct omap2_mcspi *mcspi, } } - if (t-delay_usecs) - udelay(t-delay_usecs); - omap2_mcspi_set_enable(spi, 0); if (mcspi-fifo_depth 0) -- 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] spi: omap2-mcspi: Fix native cs with new set_cs
On Fri, May 22, 2015 at 01:25:44PM +0100, Mark Brown wrote: On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote: So after reverting this patch I found there is a issue in that it is difficult to determine when a transfer is complete to properly drive the chipselect from within the transfer_one function. Is unprepare_message() a suitable place here? I've got a feeling the answer is no... Then I figured that we could handle the case when GPIOs are being used with some conditional calls to omap2_mcspi_set_cs in the omap2_mcspi_work_one function. Near the beginning of the function I added: if (gpio_is_valid(spi-cs_gpio)) omap2_mcspi_set_cs(spi, 0); Near the end of the function I added: if (gpio_is_valid(spi-cs_gpio)) omap2_mcspi_set_cs(spi, 1); This makes GPIO chip select support work while leaving the native working as previous. Is this solution acceptible? I think that's probably OK as well, it's not ideal though (and risky if the chip select is routed somewhere...). In the process of reviewing the changes I found a few other things that should be changed as well. Please send fixes for these as separate patches (ideally without any dependency on your new work so we can send them to Linus as fixes). Well actually these fixes are needed as the results of the first three patches pushed into next. When switching from transfer_one_message to tranfer_one I did not realize that the delay was handled in the core. When adding the set_cs function I did not notice that the enable was complemented by the core driver. Here you will see a delay that is already handled by the core spi driver: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/spi/spi-omap2-mcspi.c#n1166 I can't actually see that since I have no internet access right now! That's like a fish out of water. -- 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] spi: omap2-mcspi: Fix native cs with new set_cs
On Thu, May 21, 2015 at 11:18:57AM +0100, Mark Brown wrote: On Wed, May 20, 2015 at 09:07:09PM -0500, Michael Welling wrote: My guess is that the set_cs needs to be called even when toggling as GPIO. How should I handle this? It shouldn't be part of a set_cs() operation but rather part of the main transfer operation. Okay then this patch should be reverted. Do you want to revert the patch and apply a new one or should I provide a patch that reverts the changes and fixes it all in one? Sorry for this mess. -- 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] spi: omap2-mcspi: Fix native cs with new set_cs
On Thu, May 21, 2015 at 10:16:38PM +0100, Mark Brown wrote: On Thu, May 21, 2015 at 04:04:11PM -0500, Michael Welling wrote: Do you want to revert the patch and apply a new one or should I provide a patch that reverts the changes and fixes it all in one? Can you please send me separate revert and re-add patches, that's probably going to be easier to review. So after reverting this patch I found there is a issue in that it is difficult to determine when a transfer is complete to properly drive the chipselect from within the transfer_one function. Then I figured that we could handle the case when GPIOs are being used with some conditional calls to omap2_mcspi_set_cs in the omap2_mcspi_work_one function. Near the beginning of the function I added: if (gpio_is_valid(spi-cs_gpio)) omap2_mcspi_set_cs(spi, 0); Near the end of the function I added: if (gpio_is_valid(spi-cs_gpio)) omap2_mcspi_set_cs(spi, 1); This makes GPIO chip select support work while leaving the native working as previous. Is this solution acceptible? In the process of reviewing the changes I found a few other things that should be changed as well. Here you will see a delay that is already handled by the core spi driver: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/spi/spi-omap2-mcspi.c#n1166 In the set_cs function the inversion of the enable that occurs in the core spi_set_cs function based on SPI_CS_HIGH needs to revert as the controller handles the inversion with OMAP2_MCSPI_CHCONF_EPOL bit in the CHCONF register. If you approve of the fix for the GPIO support, I will provide a patch series with all of these above mentioned fixes. -- 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] spi: omap2-mcspi: Fix native cs with new set_cs
On Tue, May 12, 2015 at 08:17:58PM +0100, Mark Brown wrote: On Tue, May 12, 2015 at 12:38:57PM -0500, Michael Welling wrote: GPIO chip select patch series appears to have broken the native chip select support. This patch pulls the manual native chip select toggling out of the transfer_one routine and adds a set_cs routine. Applied, thanks It appears that in haste, this fix for the native cs support broke the GPIO chip select support that I was originally shooting for. [2.653658] mcp23s08 spi1.1: TXS timed out [2.657961] mcp23s08 spi1.1: SPI transfer failed: -5 [2.663305] spi_master spi1: failed to transfer one message from queue [2.670172] mcp23s08 spi1.1: can't setup chip 64, -- -5 [2.675784] GPIO chip mcp23s08: gpiochip_unexport: status -19 My guess is that the set_cs needs to be called even when toggling as GPIO. How should I handle this? -- 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: AM335x OMAP2 common clock external fixed-clock registration
On Fri, Apr 17, 2015 at 11:12:03AM +0200, Sebastian Hesselbarth wrote:
On 17.04.2015 04:00, Michael Welling wrote:
On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote:
On 17.04.2015 00:09, Michael Welling wrote:
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote:
On 16.04.2015 18:17, Michael Welling wrote:
[...]
What would be the proper error path?
What cleanup is required?
A proper error path would be to release any claimed resource
on any error. If you look at the code, the only resources that
need to be released are the two clocks in question.
So for every error return in the probe function and in the of si5351_dt_parse
it needs to clk_put first right?
Not quite. The driver should clk_put() every clock that it called a
[of_]clk_get() for. The thing is that clocks can be passed by
platform_data and we never claim them.
Should the ones from the platform data be claimed?
See attached patch to see if we are on the same page.
Adding a .remove() function needs more care because of the pdata passed
clocks. I admit that back when the driver was introduced clk_put()
wasn't really necessary at all.
Is it necessary now?
[...]
Here is what the kernel reports with debugging off:
Do you have any measurement equipment to check what is actually set?
Yes, I have an oscilloscope here at my desk.
The reported numbers do not always correspond to the actual output in some
cases.
is not always correspond close or way off the requested frequency?
Both.
Stability is an issue that I am aware of. Neither the datasheet nor the
appnote were clear about any order the clocks should be set or how long
we should wait between changing pll/ms/clkout parameters.
SiLabs suggests to configure all clocks at once and never change them
later, at least that is what you can read from the public documents.
The drivers you mention below can however reveal some steps that have
to be taken care of before and after changing parameters.
The drivers were not provided we wrote them and they do nothing but write
the registers with the raw values provided from the SiLab clock generator
software.
The ms2 output has appeared to stop working all together sometime whilest
testing. I may have to solder a new chip on there.
Could misconfiguration damage the chip?
You should know that a lot of things can damage a chip and
misconfiguration is among them, yes. I cannot tell if that
is the cause though.
Well I did something to the chip.
[...]
Is there any way to try out a less recent kernel, let's say two or
three releases before 4.0?
Could you provide a specific version that you think has the best chances of
working?
My guess with 2-3 releases before 4.0 was because somewhere in between
clk API must have switched from passing struct clk pointers to clk
cookies.
[...]
From your patch (that you should inline next time please):
@@ -1129,11 +1130,21 @@ static int si5351_dt_parse(struct i2c_client
*client,
return -ENOMEM;
pdata-clk_xtal = of_clk_get(np, 0);
- if (!IS_ERR(pdata-clk_xtal))
- clk_put(pdata-clk_xtal);
- pdata-clk_clkin = of_clk_get(np, 1);
- if (!IS_ERR(pdata-clk_clkin))
- clk_put(pdata-clk_clkin);
+ if (IS_ERR(pdata-clk_xtal)) {
+ dev_err(client-dev,
+ xtal clock not speficied\n);
+ return -ENODEV;
+ }
+
+ if (variant == SI5351_VARIANT_C) {
+ pdata-clk_clkin = of_clk_get(np, 1);
+ if (IS_ERR(pdata-clk_clkin)) {
+ dev_err(client-dev,
+ clkin clock not speficied\n);
+ ret = -ENODEV;
+ goto err_put_clk_of;
+ }
+ }
Basically, yes. But as I said, if you move that to the end of
si5351_dt_parse() you won't have to add
@ -1143,14 +1154,16 @@ static int si5351_dt_parse(struct i2c_client *client,
if (num = 2) {
dev_err(client-dev,
invalid pll %d on pll-source prop\n, num);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_put_clk_of;
}
this to each of the sanity checks. Claiming the clock resources at
the end saves you from tearing down the resources on each error above.
Sure I can move it down put it seems counterintuitive to parse parameters that
rely on the clocks before they are determined to be specified.
Another thing is that you now require VARIANT_C devices to always
pass both, xtal and clkin. I can live with it until we find somebody
who actually uses C-type devices with only one clock input connected.
Okay I did not realize that the C variant could run with one or the other.
Adding a .remove() function to si5351 definitely needs more care with
respect to claimed and pdata passed clocks. I am
Re: AM335x OMAP2 common clock external fixed-clock registration
On Fri, Apr 17, 2015 at 11:18:33AM +0100, Russell King - ARM Linux wrote: On Fri, Apr 17, 2015 at 11:12:03AM +0200, Sebastian Hesselbarth wrote: On 17.04.2015 04:00, Michael Welling wrote: On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote: On 17.04.2015 00:09, Michael Welling wrote: On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: On 16.04.2015 18:17, Michael Welling wrote: [...] What would be the proper error path? What cleanup is required? A proper error path would be to release any claimed resource on any error. If you look at the code, the only resources that need to be released are the two clocks in question. So for every error return in the probe function and in the of si5351_dt_parse it needs to clk_put first right? Not quite. The driver should clk_put() every clock that it called a [of_]clk_get() for. The thing is that clocks can be passed by platform_data and we never claim them. I've always said clocks (as in struct clk) should never be passed through platform data. What is the alternative for systems that still use the old platform files? Hypothetically speaking of course. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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: AM335x OMAP2 common clock external fixed-clock registration
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351
clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the
mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
I see a bug in your dt data.
snip
+ clocks {
+ ref27: ref27 {
+ #clock-cells = 0;
+ compatibale = fixed-clock;
This should be compatible, right? DT is annoying in that it doesn't
verify property names.
Ooops.
Now the clock appears in /sys/kernel/debug/clk:
root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary
clock enable_cnt prepare_cntrate
accuracy phase
ref27002700
0 0
...
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
What is the most recent upstream commit that you are based on?
I am working from 4.0.0-rc7.
7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab
Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get
in the first place, as far as I understand this destroys the clock
handle, which is still being used later in the code.
-Tero
Not sure how this ever worked. This has been in the code since the
initial commit.
Sebastian?
Regards,
Mike
+ clock-frequency = 2700;
+ };
+ };
-Tero
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no
matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
--
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: AM335x OMAP2 common clock external fixed-clock registration
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote:
On 16.04.2015 18:17, Michael Welling wrote:
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org
wrote:
[...]
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
What is the most recent upstream commit that you are based on?
I am working from 4.0.0-rc7.
7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab
Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get
in the first place, as far as I understand this destroys the clock
handle, which is still being used later in the code.
Not sure how this ever worked. This has been in the code since the
initial commit.
The reason it worked before may be related with recent rework of
clk_put() itself and clk cookies instead of pointers. I lost track on
the recent clk subsystem changes here, sorry.
However, droping the clk immediately surely isn't right.
The thing is, we can remove the clk_put() just because there is no
_remove() for that driver. I remember that back in the days the driver
was mainlined, clk removal wasn't too easy.
FWIW, as soon as _remove() support will be added by someone, we'll have
to rethink passing struct clk* by platform_data or at least
double-check if we ever used [of_]clk_get() to obtain it.
Mind to send a patch removing the clk_put() on !IS_ERR and add a proper
error path instead? While of_clk_get() is the only calls that need
cleanup on error in si5351_dt_parse() we should probably move that
calls to the end of this function. Otherwise we'd also have to cleanup
on every of_parse_foo() failure.
What would be the proper error path?
What cleanup is required?
It should be noted that there are more deep rooted issues with the driver
that I have noticed. For one the driver behaves differently if the debugging
is on and when it is off.
Here is what the kernel reports with debugging off:
root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary
clock enable_cnt prepare_cntrate accuracy
phase
ref27002700 0
0
xtal 002700 0
0
pllb 00 59994 0
0
ms0 001249 0
0
clk0 001249 0
0
plla 00 59994 0
0
ms2 00 8219178 0
0
clk2 00 8219178 0
0
ms1 0094117646 0
0
clk1 0094117646 0
0
Here is what the kernel reports with debugging on:
clock enable_cnt prepare_cntrate accuracy
phase
ref27002700 0
0
xtal 002700 0
0
pllb 00 884736000 0
0
ms0 0018432000 0
0
clk0 0018432000 0
0
plla 00 897023997 0
0
ms2 0012287999 0
0
clk2 0012287999 0
0
ms1 00 140709646 0
0
clk1 00 140709646 0
0
Note this is with the following devicetree entry:
si5351: clock-generator {
#address-cells = 1;
#size-cells = 0;
#clock-cells = 1;
compatible = silabs,si5351a-msop;
reg = 0x60;
status = okay;
/* connect xtal input to 27MHz reference */
clocks = ref27;
/* connect xtal input as source of pll0 and pll1 */
silabs,pll-source = 0 0, 1 0;
clkout0: clkout0 {
reg = 0
Re: AM335x OMAP2 common clock external fixed-clock registration
On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote: On 17.04.2015 00:09, Michael Welling wrote: On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: On 16.04.2015 18:17, Michael Welling wrote: On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: On 04/15/2015 11:51 PM, Michael Welling wrote: On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote: [...] There is still an issue with the si5351. I had to comment out the clk_put here for the frequency to show up: http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 Ideas? What is the most recent upstream commit that you are based on? I am working from 4.0.0-rc7. 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get in the first place, as far as I understand this destroys the clock handle, which is still being used later in the code. Not sure how this ever worked. This has been in the code since the initial commit. The reason it worked before may be related with recent rework of clk_put() itself and clk cookies instead of pointers. I lost track on the recent clk subsystem changes here, sorry. However, droping the clk immediately surely isn't right. The thing is, we can remove the clk_put() just because there is no _remove() for that driver. I remember that back in the days the driver was mainlined, clk removal wasn't too easy. FWIW, as soon as _remove() support will be added by someone, we'll have to rethink passing struct clk* by platform_data or at least double-check if we ever used [of_]clk_get() to obtain it. Mind to send a patch removing the clk_put() on !IS_ERR and add a proper error path instead? While of_clk_get() is the only calls that need cleanup on error in si5351_dt_parse() we should probably move that calls to the end of this function. Otherwise we'd also have to cleanup on every of_parse_foo() failure. What would be the proper error path? What cleanup is required? A proper error path would be to release any claimed resource on any error. If you look at the code, the only resources that need to be released are the two clocks in question. So for every error return in the probe function and in the of si5351_dt_parse it needs to clk_put first right? See attached patch to see if we are on the same page. It should be noted that there are more deep rooted issues with the driver that I have noticed. For one the driver behaves differently if the debugging is on and when it is off. I guess you mean #define DEBUG in the driver? Yes. Here is what the kernel reports with debugging off: Do you have any measurement equipment to check what is actually set? Yes, I have an oscilloscope here at my desk. The reported numbers do not always correspond to the actual output in some cases. The ms2 output has appeared to stop working all together sometime whilest testing. I may have to solder a new chip on there. Could misconfiguration damage the chip? root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 59994 0 0 ms0 001249 0 0 clk0 001249 0 0 plla 00 59994 0 0 ms2 00 8219178 0 0 clk2 00 8219178 0 0 ms1 0094117646 0 0 clk1 0094117646 0 0 Here is what the kernel reports with debugging on: clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 884736000 0 0 ms0 0018432000 0 0 clk0 0018432000 0 0 Is this what you expect for clk0? Yes. plla
Re: AM335x OMAP2 common clock external fixed-clock registration
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..3d2d516 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -401,7 +401,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-evmsk.dtb \
am335x-nano.dtb \
am335x-pepper.dtb \
- am335x-lxm.dtb
+ am335x-lxm.dtb \
+ som-3354-200es.dtb
dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/som-3354-200es.dts b/arch/arm/boot/dts/som-3354-200es.dts
new file mode 100644
index 000..03f06e8
--- /dev/null
+++ b/arch/arm/boot/dts/som-3354-200es.dts
@@ -0,0 +1,590 @@
+/*
+ * som-3354-200es.dts - Device Tree file for the SOM-3354M with SOM-200ES.
+ *
+ * Copyright (C) 2015 EMAC Inc.
+ * Copyright (C) 2015 QWERTY Embedded Design
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ model = EMAC SOM-3354M SOM-200ES;
+ compatible = emac,som3354, ti,am33xx;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ leds {
+ pinctrl-names = default;
+ pinctrl-0 = leds_pins;
+
+ compatible = gpio-leds;
+
+ led@0 {
+ label = stat;
+ gpios = gpio3 4 GPIO_ACTIVE_HIGH;
+ default-state = on;
+ };
+ };
+
+ vmain: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmain;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ };
+
+ backlight {
+ compatible = pwm-backlight;
+ pwms = ecap2 0 5 0;
+ brightness-levels = 0 51 53 56 62 75 101 152 255;
+ default-brightness-level = 8;
+ };
+
+ panel {
+ compatible = ti,tilcdc,panel;
+ pinctrl-names = default;
+ pinctrl-0 = lcd_pins;
+ status = okay;
+
+ enable-gpios = gpio1 13 GPIO_ACTIVE_HIGH;
+
+ panel-info {
+ ac-bias = 255;
+ ac-bias-intrpt = 0;
+ dma-burst-sz = 16;
+ bpp = 16;
+ fdd = 0x80;
+ tft-alt-mode = 0;
+ stn-565-mode = 0;
+ mono-8bit-mode = 0;
+ sync-edge = 0;
+ sync-ctrl = 0;
+ raster-order = 1;
+ fifo-th = 0;
+ };
+
+ display-timings {
+ native-mode = timing0;
+ timing0: 480x272 {
+hactive = 480;
+vactive = 272;
+hback-porch = 1;
+hfront-porch= 44;
+hsync-len = 45;
+vback-porch = 1;
+vfront-porch= 13;
+vsync-len = 14;
+clock-frequency = 900;
+hsync-active= 0;
+vsync-active= 0;
+de-active = 1;
+pixelclk-active = 1;
+ };
+ };
+ };
+
+ clocks {
+ ref27: ref27 {
+ #clock-cells = 0;
+ compatibale = fixed-clock;
+ clock-frequency = 2700;
+ };
+ };
+
+/*
+ sound {
+ compatible = ti,da830-evm-audio;
+ ti,model = SOM3354 CS4271;
+ ti,audio-codec = cs4271;
+ ti,mcasp-controller = mcasp0;
+ ti,codec-clock-rate = 12288000;
+ ti,audio-routing =
+ Line Out, AOUTA+,
+ Line Out, AOUTA-,
+ Line Out, AOUTB+,
+ Line Out, AOUTB-;
+ };
+*/
+};
+
+mcasp0 {
+ pinctrl-names = default;
+ pinctrl-0 = mcasp0_pins;
+
+ status = okay;
+
+ op-mode = 0; /* MCASP_IIS_MODE */
+ tdm-slots = 2;
+ /* 4 serializers */
+ serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
+ 2 1 0 0
+ ;
+ tx-num-evt = 2;
+ rx-num-evt = 2;
+};
+
+am33xx_pinmux {
+
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,pins =
+ 0xa0 0x00 /* lcd_data0.lcd_data0
Re: AM335x OMAP2 common clock external fixed-clock registration
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351
clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
I see a bug in your dt data.
snip
+ clocks {
+ ref27: ref27 {
+ #clock-cells = 0;
+ compatibale = fixed-clock;
This should be compatible, right? DT is annoying in that it doesn't
verify property names.
Ooops.
Now the clock appears in /sys/kernel/debug/clk:
root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary
clock enable_cnt prepare_cntrate
accuracy phase
ref27002700
0 0
...
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
What is the most recent upstream commit that you are based on?
I am working from 4.0.0-rc7.
7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab
Regards,
Mike
+ clock-frequency = 2700;
+ };
+ };
-Tero
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no
matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
--
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: AM335x OMAP2 common clock external fixed-clock registration
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
I see a bug in your dt data.
snip
+ clocks {
+ ref27: ref27 {
+ #clock-cells = 0;
+ compatibale = fixed-clock;
This should be compatible, right? DT is annoying in that it doesn't
verify property names.
Ooops.
Now the clock appears in /sys/kernel/debug/clk:
root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary
clock enable_cnt prepare_cntrate accuracy
phase
ref27002700 0
0
...
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
+ clock-frequency = 2700;
+ };
+ };
-Tero
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
--
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
AM335x OMAP2 common clock external fixed-clock registration
Greetings, I have developed an AM3354 based SoM and it uses an external SI5351 clock generator to drive the clock inputs for an external duart and I2S audio master clock. With the registration according to the documentation the reference clock is not being detected and hence the clock generator is not working as expect. After trying many different things, I started to look around the mailing lists to find information related to this issue. I came acrossed post that has the exact same issue: https://lkml.org/lkml/2013/2/18/468 Seeing as the patch did not land upstream, I am wondering if there is a solution that I am not seeing. I am willing to provide a patch given appropriate guidance. Regards, Michael -- 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: TSC2004 driver
On Wed, Aug 6, 2014 at 4:16 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Aug 06, 2014 at 10:33:18PM +0200, Joachim Eastwood wrote: On 6 August 2014 21:37, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Hi Michael, On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote: The TSC2004 driver has yet to appear in the mainline kernel. We have been using the driver referenced here as provided by TI: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html Are there any plans of supporting this device in the mainline kernel? I still believe that support for TSC2004 should be added 5to tsc2007, they are too much alike to be separate drivers. I tried to add tsc2004 support to the tsc2007 driver but I didn't really get it to work properly because the tsc2007 interrupt handling differs from what tsc2004 needs. OK. I think it would be better to add tsc2004 support to the tsc2005 driver. They only difference between those two chips is the interface (i2c vs spi). If regmap was added to tsc2005 I think it should be easy to support tsc2004. That would also be acceptable. The tsc2005 still needs devicetree conversion, so it is at least 2 patches away from where I can use it. I have missed the window for my companies OE release so I doubt I will have time to code in all or any of this. I am in the process of routing a AM335x SoM which obsoletes this AM3517 one so my resources will be elsewhere. Thanks. -- Dmitry -- 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: TSC2004 driver
On Wed, Aug 6, 2014 at 5:28 PM, Sebastian Reichel s...@kernel.org wrote: Hi, On Wed, Aug 06, 2014 at 05:13:19PM -0500, Michael Welling wrote: The tsc2005 still needs devicetree conversion, so it is at least 2 patches away from where I can use it. TSC2005 DT support has been added in 3.16: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a38cfebb56898633687ab337fd53710e63a0aedd Sorry for the misinformation. If someone else is volunteering to do the regmap support let me know. -- Sebastian -- 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
TSC2004 driver
The TSC2004 driver has yet to appear in the mainline kernel. We have been using the driver referenced here as provided by TI: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html Are there any plans of supporting this device in the mainline kernel? Mysteriously a device tree entry was found in the following file: arch/arm/boot/dts/omap4-var-som-om44.dtsi This is obviously pointing to an out of tree driver that is not easily obtained. Suggestions? -- 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: OMAP3/AM3517 EHCI USB Issue
On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote: On 08/02/2014 02:51 AM, Michael Welling wrote: On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested
Re: OMAP3/AM3517 EHCI USB Issue
On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is enabled
Re: OMAP3/AM3517 EHCI USB Issue
On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working
Re: OMAP3/AM3517 EHCI USB Issue
On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is enabled
Re: OMAP3/AM3517 EHCI USB Issue
On Wed, Jul 30, 2014 at 1:59 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working
Re: OMAP3/AM3517 EHCI USB Issue
On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is enabled? Is this a flag in an entry in the devicetree? there is a pm_debug file on debugfs which you can use. Set autosuspend delay
Re: OMAP3/AM3517 EHCI USB Issue
On Tue, Jul 29, 2014 at 12:51:45AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 11:13]: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is enabled? Is this a flag in an entry in the devicetree? there is a pm_debug file on debugfs which you can use. Set autosuspend delay to UART (it's set to -1 by default, IIRC), then leave the board idle for a couple minutes, then read /sys/kernel/debug/pm_debug and see if the OFF() counters are increasing. Adding linux-omap to Cc. Also Tony, who has a simple script to enable pm_runtime on UART. I doubt that you have off-while-idle enabled as you need to manually enable the timeouts for UARTs for it to trigger :) I would check the related power and clock lines with a scope to see if there are glitches on them. In any case, would be nice to have this EHCI stuff be sorted out for good in the mainline kernel as we do have things working pretty well for other things. Today I enabled debugging in the core hub driver and found that once the external HUB suspends, the root HUB suspends. Once the root HUB suspends, it seems there is no way for the external HUB to wake the root HUB with the hardware setup that I have. root@som3517:~# dmesg | grep hub [0.617964] usbcore: registered new interface driver hub [2.818449] hub 1-0:1.0: USB hub found [2.822980] hub 1-0:1.0: 3 ports detected [2.827354] hub 1-0:1.0: standalone hub [2.831402] hub 1-0:1.0: individual port power switching [2.837067] hub 1-0:1.0: individual port over-current protection [2.843400] hub 1-0:1.0: power on to power good time: 20ms [2.851414] hub 1-0:1.0: local power source is good [2.860133] hub 1-0:1.0: enabling power on all ports [3.169607] hub 1-0:1.0: state 7 ports 3 chg 0002 evt [3.584251] hub 1-1:1.0: USB hub found [3.592571] hub 1-1:1.0: 2 ports detected [3.597095] hub 1-1:1.0: standalone hub [3.601187] hub 1-1:1.0: individual port power switching [3.606875] hub 1-1:1.0: individual port over-current protection [3.614899] hub 1-1:1.0: TT per port [3.618711] hub 1-1:1.0: TT requires at most 8 FS bit times (666 ns) [3.625558] hub 1-1:1.0: power on to power good time: 100ms [3.654652] hub 1-1:1.0: local power source is good [3.662134] hub 1-1:1.0: enabling power on all ports [3.766183] hub 1-1:1.0: state 7 ports 2 chg evt [3.772116] hub 1-1:1.0: hub_suspend [3.804789] hub 1-0:1.0: hub_suspend Here is what happens when I echo on into the power control for the HUB afterwards: root@som3517:/# echo on /sys/bus/usb/devices/1-1/power/control [ 1050.003689] hub 1-0:1.0: hub_resume [ 1050.011306] usb usb1-port1: status 0507 change [ 1050.019975] hub 1-0:1.0: state 7 ports 3 chg evt [ 1050.028076] usb 1-1: usb auto-resume [ 1050.065904] hub 1-0:1.0: state 7 ports 3 chg evt 0002 [ 1050.084623] usb 1-1: finish resume [ 1050.092469] usb 1-1: retry with reset-resume [ 1050.156167] hub 1-0:1.0: port_wait_reset: err = -16 [ 1050.161331] usb usb1-port1: not enabled, trying reset again... [ 1050.376402] usb usb1-port1: logical disconnect [ 1050.381354] usb 1-1: gone after usb resume? status -19 [ 1050.386941] usb 1-1: can't resume, status -19 [ 1050.391537] usb usb1-port1: logical disconnect [ 1050.400203] usb usb1-port1: status 0100, change 0003, 12 Mb/s [ 1050.406410] usb 1-1: USB disconnect, device number 2 [ 1050.411650] usb 1-1: unregistering device [ 1050.604563] usb usb1-port1: debounce total 100ms stable 100ms status 0x100 [ 1050.611901] hub 1-0:1.0: state 7 ports 3 chg
Re: AM3517 fails to boot 3.16-rc5 device tree kernel
On Mon, Jul 21, 2014 at 12:09:13AM -0700, Tony Lindgren wrote: * Michael Welling mwell...@emacinc.com [140718 07:42]: On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. I downloaded the version from the test results and it did boot. OK that's good to hear. These are combining the uImage and dtb. How do you accomplish this? You need to make sure you have the appended DTB support enabled like we do in omap2plus_defconfig: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y Then just cat zImage board.dtb /tmp/zImage-dtba and run mkimage to convert it to a uImage: $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/zImage-dtba /tmp/uImage I actually discovered this and got LCD video working. Now USB host is not working. The only thing that registers is the OHCI/EHCI hosts. root@som3517:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Not sure what the problem is. The USB devices that are plugged in are powered but never detected. Any hints? 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: AM3517 fails to boot 3.16-rc5 device tree kernel
On Mon, Jul 21, 2014 at 11:38 AM, Michael Welling mwell...@emacinc.com wrote: On Mon, Jul 21, 2014 at 12:09:13AM -0700, Tony Lindgren wrote: * Michael Welling mwell...@emacinc.com [140718 07:42]: On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. I downloaded the version from the test results and it did boot. OK that's good to hear. These are combining the uImage and dtb. How do you accomplish this? You need to make sure you have the appended DTB support enabled like we do in omap2plus_defconfig: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y Then just cat zImage board.dtb /tmp/zImage-dtba and run mkimage to convert it to a uImage: $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/zImage-dtba /tmp/uImage I actually discovered this and got LCD video working. Now USB host is not working. The only thing that registers is the OHCI/EHCI hosts. root@som3517:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Not sure what the problem is. The USB devices that are plugged in are powered but never detected. Any hints? So I got the USB host to work on boot with additional entries in the devicetree. Documentation/devicetree/bindings/omap-usb-host.txt Though the devices work if plugged in at boot, any time a device is hotplugged then the device is not detected. It is powered very briefly and then off without any kernel messages. So hints from this point would be good. 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: AM3517 fails to boot 3.16-rc5 device tree kernel
On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: * mwelling mwell...@emacinc.com [140717 16:42]: I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine? Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline? I will try this. Are there any versions where the LCD output works? Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup. Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this? 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: AM3517 fails to boot 3.16-rc5 device tree kernel
On Fri, Jul 18, 2014 at 09:40:48AM -0500, Michael Welling wrote: On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: * mwelling mwell...@emacinc.com [140717 16:42]: I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine? Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline? I will try this. Adding the earlyprintk did not work. It still hangs without any messages. Are there any versions where the LCD output works? Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup. Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. How do you determine which you are booting? I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this? 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: AM3517 fails to boot 3.16-rc5 device tree kernel
On Fri, Jul 18, 2014 at 09:40:48AM -0500, Michael Welling wrote: On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: * mwelling mwell...@emacinc.com [140717 16:42]: I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine? Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline? I will try this. Are there any versions where the LCD output works? Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup. Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this? It should be noted that when you try to boot the seperate zImage and dtb from the test build it fails. This replicates my issue. Here are the two binaries that I used: http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/build_z/omap2plus_defconfig/zImage http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/dtbs/am3517-evm.dtb Here is the boot attempt: U-Boot dhcp;set serverip 10.0.2.168;tftp 0x8200 zImage; tftp 0x8000 am3517-evm.dtb;bootz 0x8200 - 0x8000 BOOTP broadcast 1 DHCP client bound to address 10.0.3.33 Using DaVinci-EMAC device TFTP from server 10.0.2.168; our IP address is 10.0.3.33 Filename 'zImage'. Load address: 0x8200 Loading: # # # # ## 2 MiB/s done Bytes transferred = 4360800 (428a60 hex) Using DaVinci-EMAC device TFTP from server 10.0.2.168; our IP address is 10.0.3.33 Filename 'am3517-evm.dtb'. Load address: 0x8000 Loading: 1.8 MiB/s done Bytes transferred = 50145 (c3e1 hex) Kernel image @ 0x8200 [ 0x00 - 0x428a60 ] ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Device Tree to 9ff05000, end 9ff143e0 ... OK Starting kernel ... Using the exact same boot sequence worked for 3.10 and 3.14. 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
