Re: [PATCH] ARM: OMAP2: erratum I688 handling disabled for AM335x
Hi Richard, On Fri, Sep 25, 2015 at 08:44:29PM +, Woodruff, Richard wrote: > > From: Menon, Nishanth > > Sent: Friday, September 25, 2015 9:44 AM > > > > If I688 is not needed on am335x, then it seems there are still some > > > mysteries remaining with this erratum to unravel. Something like > > > difference in the L3 implementation. Maybe somebody from TI can > > > investigate which SoCs this is really needed on? > > > + Richard who probably has the oldest history on the topic. > > > > I suspect strongly that the erratum was discovered during A9 OMAP4 days, > > but never percolated to older SoC erratum documentation. The need of > > barrier logic was clarified with SoC folks to confirm the behavior though. > > -0- > After looking up i688 in data base and reviewing AM335x SOC I do NOT think > i688 will exhibit for AM335x. > - it appears not to be using pieces which have issues on path. > > I688 could impact SOCs which use a DMM and the interconnect infrastructure > which supports it. > > I believe hang issues on path could be mapped to 3 sources: > - asyncbrige used from MPUSS to Arteris NOC to DMM > - Dual EMIF idle (ocp-connect/disconnect) policy on path > - PL310 idle signal usage on path > > SOCs using similar chassis components of OMAP4430 time are impacted. Errata > aspect in generic bridge map to Aegis, J5E, ... > > The hangs are brought out by enabling power management features which causes > micro-idles on path which can trigger a lock up. > > Later SOCs pulled in fixes in one or all areas. Some SOCs are not using > components. > > -1- > Barrier side effects of the patch may be beneficial for other reasons. But > AM335x should be immune from this particular issue. Is this a matter of fact, or just an assumption? Could you clarify this with the TI hardware folks? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] ARM: OMAP2: erratum I688 handling disabled for AM335x
On Tue, Sep 29, 2015 at 06:06:36PM +, Woodruff, Richard wrote: > > From: Robert Schwebel [mailto:r.schwe...@pengutronix.de] > > Sent: Tuesday, September 29, 2015 12:50 PM > > > -1- > > > Barrier side effects of the patch may be beneficial for other reasons. > > > But > > AM335x should be immune from this particular issue. > > > > Is this a matter of fact, or just an assumption? > > Could you clarify this with the TI hardware folks? > > Which point are you asking for clarification on? > > -0- is factual. The conditions to trigger bridge bugs are specific and tied > to cited component issues. These factors can lead to a HW clock gate before > completion of bus protocol. The result is a misaligned of HW FIFO pointer > inside of the retiming bridge. At hang it is possible to attach through > JTAG-DAP and see writes going to the wrong address due to misalignment. The > bridge component did fail in simulation and was fixed per hw-bug database as > I mention. In my sampling of customers which ramped with aggressive power > management ~10/10 I worked with hit this issue on 4430 on robustness tests. > We did verify signatures at hang. > > There may be other errata which have a hang condition which users experience > but their root cause is not the same as i688. Really any action which > results in a bus protocol violation can end up in a hang. For instance a > wrong sequencing of DSS pipeline/DMA control can cause the IP to crash. If > the IP crashes while in the middle of talking with DDR a hang will result. > There is no timeout on the interconnect so a watchdog will be needed to > recover from such events. > > -1- is partially an assumption based on previous Linux macros and code > structure. Thanks for the explanation! rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: EDMA oftree entry for AM335x
On Wed, May 06, 2015 at 07:39:52AM -0700, Tony Lindgren wrote:
In different SoC we can have different number of CCs (OMAP-L138 has two) and
each CC can have different number of TCs associated with. In AM335x we have
one CC with 3 TC, in OMAP-L138 we have two CC, CC0 has 2 TC, CC1 has 1 TC.
The
TCs are used to set priorities, you can assign the priorities to the TCs and
you can choose to assign the transfer (channel) to a give TC.
OK
And yes, both TC and CCs can generate interrupts.
Do the TCs have a shared interrupt that could be handled by
each TC instance?
Separate IRQ lines to the ARM core, but we do not handle them right now.
OK
So it is not straight forward to separate the TC from the CC driver
(edma3).
It seems pm runtime for these four separate modules needs to be
done at the CC driver level if it can't be done separately for
each instance.
The current eDMA stack is not really flexible on this IMHO.
I think the way forward would be something like this in DT:
edma_cc: edma_cc@4900 {
compatible = ti,edma3-cc;
ti,hwmods = tpcc
reg = 0x4900 0x1,
0x44e10f90 0x40;
interrupts = 12 13 14;
#dma-cells = 1;
edma3_tc0: edma3_tc0@4980 {
compatible = ti,edma3-tc;
ti,hwmods = tptc0
};
edma3_tc1: edma3_tc1@4990 {
compatible = ti,edma3-tc;
ti,hwmods = tptc1
};
edma3_tc2: edma3_tc2@49a0 {
compatible = ti,edma3-tc;
ti,hwmods = tptc2
};
};
Yeah that would be an improvment and remove the blockers for further
hwmod work. It would still be better to have the TC probe separately
and register with CC rather than combining separate elements in DT
in a way that does not represent the hardare. There's a 7MB reserved
block inbetween there..
The driver for ti,edma3-tc would be pretty minimal, doing only pm_runtime
only
and from the CC driver we could just set the runtime status for the the TC
which we are about to submit work and decrement the runtime when the work is
done. If not work is needed for the TC it can be shot down.
OK
But this would need significant amount of work which can be done when we get
rid of the legacy (arch/arm/common/edma.c) and move to dmaengine only mode.
That may never happen considering that davinci is using it too.. It's
best to not count on that happening anytime soon at least.
So my current understanding is that we have the situation that the
kernel warns about the oftree being wrong, but isn't able to handle an
oftree that would be right.
Shouldn't the warning being added when the kernel driver supports that
new mechanism?
I had a warning free mainline kernel without patches on my customer
hardware before, so this smells a bit like a regression ... :-/
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: EDMA oftree entry for AM335x
Hi Tony,
On Mon, May 04, 2015 at 07:11:03AM -0700, Tony Lindgren wrote:
Adding Peter to Cc as well.
You didn't :)
The patch description says the device should be split into more devices
instead
of specifying several ti,hwmods entries, but unfortunately the Documentation
still suggests the above format in
Documentation/devicetree/bindings/dma/ti-edma.txt.
How would a correct entry look like?
Each tptc instance has it's own sysconfig register. This means each
one of them can be clocked and idled independently. They should be
treated as separate device instances. I believe the interrupts all
belong to the tpcc, which should be also treated as a separate
device instance.
In order to get rid of the ti,hwmods property, we want to have a
1-1-1 mapping of the compatible property, ti,hwmod property, and
the device entry.
Looking at the TRM Table 2-1. L3 Memory Map, these all are on
the L3, so they should be like this for now (assuming the
interrupts all belong to tpcc):
ocp {
...
edma: tpcc@4900 {
compatible = ti,edma3;
ti,hwmods = tpcc;
reg = 0x4900 0x1;
interrupts = 12 13 14;
#dma-cells = 1;
};
tptc0: tptc@4980 {
compatible = ti,tptc3;
ti,hwmods = tptc0;
reg = 0x4980 0x1;
};
tptc1: tptc@4990 {
compatible = ti,tptc3;
ti,hwmods = tptc1;
reg = 0x4990 0x1;
};
tptc2: tptc@49a0 {
compatible = ti,tptc3;
ti,hwmods = tptc2;
reg = 0x49a0 0x1;
};
...
};
I tried this, with the patch below, but it doesn't work:
--8-- Output with 4.1-rc1 vanilla --8--
Loading ARM Linux zImage '/mnt/mmc0.1//boot/zImage'
Loading devicetree from '/mnt/mmc0.1//boot/am335x-afi-gf.dtb'
commandline: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4
rootwait loglevel=6
[0.00] Linux version 4.1.0-rc1 (rsc@callisto) (gcc version 4.8.3
2013 (prerelease) (OSELAS.Toolchain-2013.12.2 linaro-4.8-2013.11) ) #9
PREEMPT Mon May 4 22:24:41 CEST 2015
[0.00] earlycon: no match for ttyO2,115200n8
[0.00] Kernel command line: console=ttyO2,115200n8
root=/dev/mmcblk0p2 rootfstype=ext4 rootwait loglevel=6
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
[0.00] .text : 0xc0008000 - 0xc0674ed4 (6580 kB)
[0.00] .init : 0xc0675000 - 0xc06b2000 ( 244 kB)
[0.00] .data : 0xc06b2000 - 0xc06fd3e8 ( 301 kB)
[0.00].bss : 0xc070 - 0xc073a5d8 ( 234 kB)
[0.145038] omap_hwmod: tptc0 using broken dt data from edma
[0.145247] omap_hwmod: tptc1 using broken dt data from edma
[0.145425] omap_hwmod: tptc2 using broken dt data from edma
[0.151051] omap_hwmod: debugss: _wait_target_disable failed
[0.323079] SCSI subsystem initialized
[0.356218] NFS: Registering the id_resolver key type
[0.356339] Key type id_resolver registered
[0.356354] Key type id_legacy registered
[0.518782] 47401300.usb-phy supply vcc not found, using dummy regulator
[0.532356] 47401b00.usb-phy supply vcc not found, using dummy regulator
[0.554370] Key type dns_resolver registered
[0.559333] omap_voltage_late_init: Voltage driver support not added
[0.775905] mmc0: host does not support reading read-only switch, assuming
write-enable
[1.140875] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_vrise (80,
SessEnd), retry #3, port1 0008010c
[1.561977] random: systemd urandom read with 17 bits of entropy available
Welcome to PTXdist / af inventions-GF!
userspace starts
--8-- Output with patch --8--
[0.00] Linux version 4.1.0-rc1+ (rsc@callisto) (gcc version 4.8.3
2013 (prerelease) (OSELAS.Toolchain-2013.12.2 linaro-4.8-2013.11) ) #10
PREEMPT Mon May 4 23:03:27 CEST 2015
[0.00] earlycon: no match for ttyO2,115200n8
[0.00] Kernel command line: console=ttyO2,115200n8
root=/dev/mmcblk0p2 rootfstype=ext4 rootwait loglevel=6
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[
