Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery
On 13 January 2016 at 19:18, Nishanth Menon wrote: > As you already see it is ridiculously round about way of protecting RTC > time.. but anyways, for what ever reason, that was mandatory function to > support on certain product lines. Having secure date/time is probably necessary for some digital rights management schemes; e.g. you rent a movie for limited time, but it may not always be acceptable to require working internet connectivity to be able to hit the play button hence the need to rely on a secure RTC. There wouldn't even be an SMC for setting the RTC, probably it would synchronize when the secure-world shizzle contacts the Big Server O'Secrety Bits. :P Protecting pinmux through the L4 firewall sounds hilarious: the whole ctrl_core module (0x4a002000 - 0x4a002fff) is a single firewall region. All permitted access to it by linux would have to be redirected to an SMC or similar. On 13 January 2016 at 20:05, Nishanth Menon wrote: > An internal feedback I got some time back on AM57 (not OMAP5) - context > was that we were discussing if an external pull up resistor was needed > for a GPIO button: > "Internal pull-ups are relatively weak (ranging to 100kOhm or higher) Unlike the OMAP5, AM57xx uses 1.8V/3.3V drivers for its generic IOs, which have to do magic to not get fried by such high voltages. Crappier specs result, especially for pulling up to 3.3V: 1.8V mode, pull-down current while pin is held high: 50-210 uA 3.3V mode, pull-down current while pin is held high: 40-200 uA 1.8V mode, pull-up current while pin is held low: 60-200 uA 3.3V mode, pull-up current while pin is held low: 10-290 uA Note the worst-case equivalent pull-up resistance in 3.3V mode is 330 kOhm, eleven times higher than in 1.8V mode. Matthijs
[PATCH] pty: fix O_CLOEXEC for TIOCGPTPEER
It was being ignored because the flags were not passed to fd allocation.
Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl")
Signed-off-by: Matthijs van Duin
---
drivers/tty/pty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index b0e2c4847a5d..678406e0948b 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -625,7 +625,7 @@ int ptm_open_peer(struct file *master, struct tty_struct
*tty, int flags)
if (tty->driver != ptm_driver)
return -EIO;
- fd = get_unused_fd_flags(0);
+ fd = get_unused_fd_flags(flags);
if (fd < 0) {
retval = fd;
goto err;
--
2.18.0
Re: [PATCH 3.18 00/39] 3.18.53-stable review
On Thu, May 11, 2017 at 02:16:07PM -0700, Guenter Roeck wrote: > arch/arm/mach-omap2/omap-headsmp.S:60: Error: bad instruction `badr > r0,hyp_boot' > > I see "badr" used in later kernels, but not in v3.18. Does this possibly > require some secondary patches ? It was introduced in kernel 4.2 by 14327c662822 "ARM: replace BSYM() with badr assembly macro" The correct backport would therefore just be: - adr r0, hyp_boot + adr r0, BSYM(hyp_boot) Right?
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 28 May 2015 at 18:01, Tony Lindgren wrote: > For failed device access you get an interrupt Well for failed reads you get a bus error, and "catching" those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 00:24, Tony Lindgren wrote: > Hmm I believe the interrupt happens immediately trying to access an > invalid device. But maybe I'm thinking about just errors if a device > is not powered or clocked. It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting in a (synchronous) bus error which takes precedence over the out-of-band error irq (if any is signalled). Once the write is posted however, the cpu will receive an ack on the write and continue execution, and there's no reason to assume that an error irq will happen *immediately* after the write. Of course it typically will happen soon afterwards, possibly even before the next instruction is executed, depending a bit on how soon after the posting-point the error occurs versus how long it takes for the write-ack to reach the cpu. On the other hand, it's also possible the write, after becoming posted, gets stuck for a while due to a burst of higher-priority traffic. (I also recall reading about some situation where a request needs to wait for something to be dynamically powered up before an error response could be generated, but I think that was on the OMAP 4.) So that's the icky part: it will very likely happen almost immediately. There's however no *guarantee* that it will, and in fact it's quite tricky to absolutely make sure a write is no longer in transit. The usual solution is an "OCP barrier": a read that is known to follow the same path as the write. Normally that means a read from the same peripheral, but that would defeat the purpose in this case. Fortunately, the L4 interconnects (unlike the L3) detect firewall violations in the initiator agent rather than the target agents, hence a read from any peripheral on the same L4 interconnect suffices. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 02:58, Matthijs van Duin wrote: > It is only guaranteed to happen immediately (before the next > instruction is executed) if the error occurs before the posting-point > of the write. However, in that case the error is reported in-band to > the cpu, resulting in a (synchronous) bus error which takes precedence > over the out-of-band error irq (if any is signalled). OK, all this was actually assuming linux uses device-type mappings for device mappings, which was also the impression I got from build_mem_type_table() in arch/arm/mm/mmu.c (although it's a bit of a maze). A quick test however seems to imply otherwise: ~# ./bogus-dev-write Bus error So... linux actually uses strongly-ordered mappings? I really didn't expect that, given the performance implications (especially on a strictly in-order cpu like the Cortex-A8 which will really just sit there picking its nose until the write completes) and I think I recall having seen an OCP barrier being used somewhere in driver code... Well, in that case everything I said is technically still true, except the posting point is the peripheral itself. That also means the interconnect error reporting mechanism is not really useful for probing since you'll get a bus error before any error irq is delivered. So I'd say you're back at having to trap that bus error using the exception handling mechanism, which I still suspect shouldn't be hard to do. Or perhaps you could probe the device using a DMA access and combine that with the interconnect error reporting irq... ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 29 May 2015 at 17:50, Tony Lindgren wrote:
> I believe some TI kernels use strongly-ordered mappings, mainline
> kernel does not. Which kernel version are you using?
Normally I periodically rebuild based on Robert C Nelson's -bone
kernel (but with heavily customized config). I also tried a plain
4.1.0-rc5-bone3, the generic 4.1.0-rc5-armv7-x0 (the most
vanilla-looking kernel I could find in my debian package list), and
for the heck of it also the classic 3.14.43-ti-r66.
In all cases I observed a synchronous bus error (dubiously reported as
"external abort on non-linefetch (0x1818)") on an AM335x with this
trivial test:
int main() {
int fd = open( "/dev/mem", O_RDWR | O_DSYNC );
if( fd < 0 ) return 1;
void *ptr = mmap( NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0x4200 );
if( ptr == MAP_FAILED ) return 1;
*(volatile int *)ptr = 0;
return 0;
}
I even considered for a moment that maybe the AM335x has some "all
writes non-posted" thing enabled (which I think is available as a
switch on OMAP 4/5?). It seemed unlikely, but since most of my
exploration of interconnect behaviour was done on a DM814x, I
double-checked by performing the same write in a baremetal test
program (with that region configured Device-type in the MMU). As
expected, no data abort occurred, so writes most certainly are posted.
So I have trouble coming up with any explanation for this other than
the use of strongly-ordered mappings.
(Curiously BTW, omitting O_DSYNC made no difference.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 1 June 2015 at 19:58, Tony Lindgren wrote: > I think these kernels are missing the configuration for l3-noc > driver? Yup. Since I'm pretty sure I have all the necessary info I was hoping look into that... somewhere in my copious spare time... > I tried it on omap4 that has l3-noc configured, and it first produces > "Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fd7000", (Though making a patch to fix that annoyingly wrong and useless message is higher on my list of priorities) > and the L3 interrupt only after that. So yeah, you're right, we can't > use the interrupts here. I somehow remembered we'd get only the L3 > interrupt if configured. The bus error is not influenced by L3 error reporting config afaik, and it will always win from the irq: even though the irq is almost certainly asserted first, it can't be taken until the load/store instruction completes, and then the fault will take precedence. While implementing L3 error reporting in my forth system I ran into a tricky scenario though: it turns out that if an irq occurs while the cpu is waiting for instruction fetch, it does allow the irq to be taken. The interrupted fetch is abandoned and any bus error it may have produced is ignored since exception entry/exit is an implicit instruction sync barrier. On return it is simply refetched... Hence, the result from attempting to execute code from an invalid address: fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] ... (repeat until watchdog expires) Anyhow, so we still have the puzzling fact that apparently neither of us was expecting device memory to use a strongly-ordered mapping, getting a bus error on a write (outside MPUSS itself) shows that it does. I've tried to read arch/arm/mm/mmu.c to find out why, but so far I'm feeling hopelessly lost there... (the multitude of ARM architecture versions/flavors supported aren't helping.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 1 June 2015 at 22:52, Tony Lindgren wrote: > OK that must be the case I've seen then. Probably that happens > when a device is not clocked. It happens for any interconnect error reported as a result of instruction fetch, but that is itself not a very common occurrence and obviously doesn't apply to device memory. Another case where the L3 error irq may be taken first is if the bus error is asynchronous, but I don't think this combo can be produced on a dm81xx or am335x, but that's mainly due to the strictly in-order Cortex-A8 making almost every abort synchronous. I'd expect async aborts are more common on an A9. > Hmm well it should be just MT_DEVICE for anything Linux ioremaps.. Yikes, so both /dev/mem and uio are behaving unlike any device driver: both use remap_pfn_range() after running the vm_page_prot though pgprot_noncached() to set the memory type to L_PTE_MT_UNCACHED, which counterintuitively turns out to mean strongly-ordered. o.O Especially uio is acting inappropriate here imho. But this is problematic... these ranges are already mapped by the kernel, and ARM explicitly forbids mapping the same physical range twice with different memory attributes (and it's not the only architecture to do so). Hmmz... Anyhow, drifting a bit off-topic here. I'm going to some more reading and thinking about this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency
On 3 May 2016 at 18:43, Tony Lindgren wrote: > Does a fixed divider calculation of input * (32768 / 27e6) make sense > here too as pointed out earlier by Matthijs for the ti81xx? That was an actual fractional divider, i.e. the output clock would be exactly that ratio of the input clock, which would therefore yield 32768 Hz if the default crystal is used for the main osc. It makes no sense to use it to describe a wobbly RC osc. On 3 May 2016 at 19:32, Tero Kristo wrote: > Also, as it is security related, this is kind of sensitive area to discuss > publicly. Don't be silly. The only sense in which this clock is "security related" is because it's used for the secure watchdog, and the reason to use it despite its inaccuracy is completely obvious: an internal rc osc can't be easily manipulated by an external attacker. I see no reason to act all cloak-and-dagger about this. (This seems to be a general theme to conceal "security related" things from public documentation. If I were an HS customer I'd actually be concerned about such behaviour since it would seem to indicate a lack of confidence in one's security architecture.) Matthijs
Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx
On 2 December 2015 at 00:38, Tony Lindgren wrote: > Looks like GPIO softreset status bit on both dm8168 and dm8148 > is broken and only goes high initially. After writing to sysc > softreset bit, the resetdone bit never goes high again. The resetdone bit works fine, but it needs all clocks active to come up. You're neglecting to enable the debounce clock to the GPIO module: > # mw.l 0x4818155c 0x2 That should write 0x102 instead. You can disable the debounce clock after resetting the module if you don't need it, though I doubt there's any significant power savings there. (More likely it exists as a separate bit to allow it to stay enabled even if the module isn't, for wakeup on debounced inputs.) Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask
On 2 December 2015 at 00:38, Tony Lindgren wrote: > - pinctrl-single,function-mask = > <0x300ff>; > + pinctrl-single,function-mask = > <0x707ff>; Reminder that silicon revision 2.1 and older require input enabled (bit 18 set) for all 3.3V I/Os to avoid cumulative hardware damage. (Errata advisory 2.1.87) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask
On 2 December 2015 at 01:46, Tony Lindgren wrote: > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? Can't we just keep bit 18 out of the function mask? The bootloader should already have made sure all pins have bit 18 set (and bit 19 set to correct values after ROM mucked them up, see advisory 2.1.88), so all that needs to be done is avoid touching them. Are the power savings from disabling unnecessary inputs significant enough to spend any headache on it? Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask
On 2 December 2015 at 01:46, Tony Lindgren wrote: > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? I'm in general no fan of such macros: it feels really awkward to have to make that distinction in dts when doing pin config. Note that if you're feeling really enthausiastic about putting in effort to allow inputs to be disabled while staying clear of the erratum, I think you can detect at runtime which I/O supplies are 3.3V by inspecting this register: #define CTRL_CQDETECT_STATUS0x48140e00 Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] phy: Add a driver for dm816x USB PHY
On 17 March 2015 at 03:19, Tony Lindgren wrote: > Yes so it seem here too, this is dm816x rev c, what do you have? jtag ID reads 0x1b81e02f, so that would be rev 1.1 / rev A. > Anyways, I'll add a note that at least rev c does not seems to do > anything with USB_CTRL but that we follow what the TI tree is doing > in case some other revisions of the hardware use it. Another idea would be to check if it's nonzero and if so, yell loudly in the kernel log that they should mail the linux-omap list ;-) Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] phy: Add a driver for dm816x USB PHY
Given that the documentation mentions the actual phy used, it may be worth mentioning this also in the driver? i.e. that it's not a "dm816x phy" but a "SR70LX Synopsys USB 2.0 OTG nanoPHY" (in contrast to the dm814x and am335x which use a phy TI made themselves) USB is one of the few subsystems of the DM814x I've never really examined in any detail, but it appears nearly identical to the AM335x. (e.g. the phy registers in the control module are nearly identical, differing only in some bits related to GPIO-mode) On 9 March 2015 at 22:41, Tony Lindgren wrote: > Note that we still are missing basic support for dm814x in mainline, > I'm planning to tackle that at some point but I don't know when I'm > going to get to it.. Do ping me if you have questions. While I still don't have time to really throw myself on the task myself, and I'm still hindered by insufficient knowledge of the kernel, I do have quite a bit of experience with the processor itself. BTW, w.r.t. the old "official" TI kernel for dm81xx: there are actually two relevant forks of the unmaintained arago-omap3/ti81xx-master branch, namely: http://arago-project.org/git/projects/?p=linux-ipnc-rdk-dm81xx.git http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git which contain various bugfixes, including for usb (though also patches specific to those SDKs). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] phy: Add a driver for dm816x USB PHY
On 13 March 2015 at 20:30, Tony Lindgren wrote: > Hmm OK have to check that. It could also be that dm816x documentation > is copy-paste from da850 or am3517 and the PHY got changed in the > hardware as the registers don't match the documentation. Only the > dm816x errata has right documentation for the USB PHY. Hmm? While I see plenty of usb errata (mostly DMA bugs), I don't see anything about registers being different. I do see something curious: advisory 70, the only PHY-related erratum I see, is also present in the DM814x errata and even in AM335x r1.0. This strongly suggests the PHYs must at least be closely related... The dm816x TRM makes three separate mentions of the synopsys usb phy though, while I found no other TRMs that mention it, so if it's a copy-paste error (which certainly would not be exceptional) I don't know where from. I suppose it's still possible TI acquired a sufficiently permissive license for the synopsys phy to fork it and call it a "TI PHY" as they do in the AM335x docs. (No mention of its origin is made in the DM814x docs.) BTW, da850? Is that yet another instance of Primus? (i.e. omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] phy: Add a driver for dm816x USB PHY
*gets increasingly confused* The datasheet (sprs614e) only contains register addresses, and they seem to match the TRM's USB chapter. The only disagreement I can spot is related to USB_CTRL register(s) in the control module (offsets 0x620 and 0x628) where * the TRM claims both exist in the control module chapter (1.16.1.3), one for each both * the TRM's USB chapter claims only one exists, and its layout (24.9.8.2) doesn't resemble the former one * the datasheet agrees only one exists (but gives no layout) * reality seems to disagree with both: I booted up our evm816x, plugged in a mouse to confirm USB is functional, and attached JTAG: both registers read as zero (contradicting both layouts) and appear to ignore writes. There doesn't seem to be any disagreement in the docs about the USBPHY_CTRL regs (offsets 0x624 and 0x62c in control module) as far as I can tell, and the documented reset values also match what I see via JTAG. > But dm814x [..] seems to be wired up like am335x. This I mentioned: the only difference is related to GPIO mode (which on the dm814x yields exactly that: GPIO, while the am335x uses it to hook up UARTs). > Yes I checked am3517 trm, and that too mentions Synopsys once Only in its ECHI/OCHI host controller, not the OTG one... Anyhow, I didn't expect this small observation to end up becoming a device archeology expedition, sorry about that ;-) >> BTW, da850? Is that yet another instance of Primus? (i.e. >> omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) > > Yes it's the arm926 based series, l-138 is da850 I believe. Ah, but there are two such series: Freon and Primus. Just to be different, their part numbers are both allocated from the omap-L1xx (arm+dsp) / tms320c674x (dsp only) / am1xxx (arm only) ranges, but distinguished by Freon having even final digit while Primus has odd final digit. Of course this doesn't hold for the da8xx parts, that would be too consistent. But you're right, da850 indeed seems to be a Freon rather than a Primus based on some more googling (apparently da850 has SATA -- Primus doesn't). Matthijs On 16 March 2015 at 17:49, Tony Lindgren wrote: > * Matthijs van Duin [150314 14:04]: >> On 13 March 2015 at 20:30, Tony Lindgren wrote: >> > Hmm OK have to check that. It could also be that dm816x documentation >> > is copy-paste from da850 or am3517 and the PHY got changed in the >> > hardware as the registers don't match the documentation. Only the >> > dm816x errata has right documentation for the USB PHY. >> >> Hmm? While I see plenty of usb errata (mostly DMA bugs), I don't see >> anything about registers being different. > > Sorry it seems to be the partially updated TRM instead, it's the > sprs614e.pdf instead. That has the USBPHY_CTRL registers right. > No mention of Synopsys in sprs614e.pdf though so who knows. It > seems something got swapped compared to the TRM as the USB_CTRL > registers totally changed. > > I'll just add a comments you mentioned earlier about it probably > being Synopsys phy. > >> I do see something curious: advisory 70, the only PHY-related erratum >> I see, is also present in the DM814x errata and even in AM335x r1.0. >> This strongly suggests the PHYs must at least be closely related... > > Hmm interesting. But dm814x has again different USB_CTRL registers, > seems to be wired up like am335x. Also there's no USBPHY_CTRL > registers on dm814x or am335x. Chances are that dm814x is wired up > the same way as am335x. > >> The dm816x TRM makes three separate mentions of the synopsys usb phy >> though, while I found no other TRMs that mention it, so if it's a >> copy-paste error (which certainly would not be exceptional) I don't >> know where from. > > Yes I checked am3517 trm, and that too mentions Synopsys once, but > has different registers. And also checked the l-138/da850 TRM, and > that does not have USB_CTRL and USBPHY_CTRL registers either.. Looks > like the copy paste errors come from tms320dm6446.pdf that has > the USB_CTRL and USBPHY_CTRL registers, but then no mention of > Synopsys. > >> I suppose it's still possible TI acquired a sufficiently permissive >> license for the synopsys phy to fork it and call it a "TI PHY" as they >> do in the AM335x docs. (No mention of its origin is made in the DM814x >> docs.) >> >> BTW, da850? Is that yet another instance of Primus? (i.e. >> omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) > > Yes it's the arm926 based series, l-138 is da850 I believe. > > Regards, > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings
On Thu, 14 Feb 2019 at 12:08, Roger Quadros wrote: > The beagleboard community is a primary user of this driver and we need to > find a solution so that PRUSS is usable either via remoteproc or via UIO. While being able to switch drivers without changing the DT by forcibly binding a different driver would definitely be a nice feature, and would have been possible with the older remoteproc-pru bindings, I think it's a stretch to say this "needs" a solution. Right now, in practice, selection between uio-pruss and remoteproc-pru is done simply by modifying the device tree appropriately (typically by having u-boot apply an overlay to the DT), and I don't think anyone views this as unduly burdensome? Matthijs
Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()
To clarify, this patch effectively reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle except it leaves behind unnecessary verbiage that this commit introduced. And to be clear, that commit *should* indeed be reverted, although preferably in its entirety obviously. of_get_next_parent already drops a ref on its argument, so of_node_put was never "missing" here. Matthijs
Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()
> [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port@1/endpoint > [8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss]) I can confirm that reverting 2ab9f5879162 fixes this regression, tested on omap5-uevm. Matthijs
Re: [RFC 1/1] drivers: i2c: omap: Add slave support
Greetings, unfortunate souls trying to use the omap-i2c peripheral in slave mode! :-) I recently posted some stuff about exactly that topic on TI's E2E forum, you may want to read this warning: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1955843#1955843 and post contains suggestions on using slave mode and details on the peripheral actually behaves: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1959417#1959417 Matthijs
Re: [RFC 1/1] drivers: i2c: omap: Add slave support
On 27 August 2016 at 19:22, Wolfram Sang wrote: > Uh, that sounds like bad HW... Making a mess of I2C controllers seems to be a popular hobby among chip designers :P ( I also really like how the RPi handles clock stretching... *cough* ) > While it surely is nice to have super detailed information, can you give > this overloaded maintainer a few-line, high level summary of what is > written there? What's written there is what should have been in the docs: correct (as in reality-matching) details of how the thing actually works in slave mode, and how to operate it without risking race conditions. They're not comprehensive, and certainly not polished since they are my personal notes I've made while studying the peripheral in detail, but I figured both on E2E and here I might perhaps save time and frustration by making them available. A lot of the details (including the completely bizarre behaviour of its innocuous-looking irq registers) would be quite non-trivial to figure out without putting in a similar effort. Matthijs
Re: [RFC 1/1] drivers: i2c: omap: Add slave support
On 28 August 2016 at 07:35, Wolfram Sang wrote:
> Well, I2C is simple, what could go wrong? :/
Actually I2C is elegant and *seems* simple, but in all its
asynchronicity there are actually a surprising number of fine details
you can trip over. Maybe that's why so many i2c controllers suck: since
i2c looks simple enough manufacturers are easily tempted to roll their
own instead of licensing a good implementation.
Having said that, most of the inconsistency and obnoxiousness of the TI
I2C controller is not even excusable by that argument. For example its
irq registers *look* like the usual set { rawstatus, status, en, dis }
that's their current standard ("Highlander") for peripherals. They do
not however *behave* like the standard set however:
1. status isn't always (rawstatus & enabled)
2. status != 0 does not always imply the irq output is asserted
3. some enable-bits also change the behaviour of rawstatus
All of these misbehaviours are unprecedented afaik.
Normally you'd also expect each irq (raw)status bit to either
a. be an event, set by hw and can be cleared by software any time, or
b. be a level status, unaffected by software attempts to set/clear.
Again the i2c controller decided this is far too little diversity.
> So, it is possible to make a proper I2C slave with OMAP, but you need
> to know those 100 gory details?
Mostly. There are some limitations such as:
* No ability to selectively ACK/NACK when addressed as slave. If you're
unable to respond for some time then you'd end up blocking the bus with
clock stretching. You could temporarily deconfigure your slave address
but the TRM states changing slave address is forbidden while bus busy.
* According to my notes it always ACKs a General Call and this cannot
even be stalled using the SBLOCK register. Since I don't care about GC
there's no more details in my notes, but if this is true then on any bus
where GC is used, irq handling will have real-time deadlines to avoid
losing track of transaction boundaries and misinterpreting data.
Finally, as my first link pointed out, various protocol errors can lock
up the peripheral's internal state machine. When operating as slave
this is basically undetectable: all registers look normal and the
bus-busy bit will continue to track start/stop, but the peripheral will
not ACK any slave address anymore until you reset it.
You could argue "well, but that requires bus protocol errors" but it is
nevertheless a direct violation of the I2C standard:
I2C-bus compatible devices must reset their bus logic on receipt
of a START or repeated START condition such that they all
anticipate the sending of a slave address, even if these START
conditions are not positioned according to the proper format.
Also, my testing showed pulsing SDA low on an idle bus sufficed to
trigger this state. It needs to pass the glitch filter of course, but
this filter is implemented by sampling the bus requiring two consecutive
samples to agree. Two small glitches with just the right timing would
therefore suffice. Rather unlikely for random noise, but having lots of
signals on your pcb that ultimately derive from the same clock source
probably makes the odds a lot more favorable.
Matthijs
Re: [PATCH v3] crypto: omap-aes: Add support for GCM mode
On 15 September 2015 at 15:28, Lokesh Vutla wrote: > --- a/drivers/crypto/Kconfig > +++ b/drivers/crypto/Kconfig > @@ -293,6 +293,7 @@ config CRYPTO_DEV_OMAP_AES > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP2PLUS > select CRYPTO_AES > select CRYPTO_BLKCIPHER > + select CRYPTO_AEAD Is it appropriate that this also selects CRYPTO_AEAD on omap2/omap3, even though they do not support GCM? > +#define AES_REG_CTRL_GCM GENMASK(17, 16) Instead of adding these definitions one bit at a time, can't we get the whole list over with at once? This thing supports: ECB, CBC, and CFB-128 encryption CTR and F8 encryption with 16/32/64/96/128-bit counter XEX (disk encryption) CBC-MAC authentication including the CMAC/OMAC/PMAC subflavors F9 authentication GCM and CCM aead (and raw GHASH, if you happen to have a use for it) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/1] drivers: i2c: omap: Add slave support
On 14 October 2016 at 09:56, Ravikumar wrote:
> Dynamic switching on OMAP I2C IP could be a difficult task.
In fact I wouldn't even bother trying. The thread I linked to received
some follow-up by someone wrestling with this and it actually resulted
in the suggestion to use separate master-only and slave-only peripherals
on the same bus just to avoid the horrible race conditions:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1990938#1990938
On 14 October 2016 at 10:57, Ravikumar wrote:
>
> On Monday 29 August 2016 09:13 AM, Matthijs van Duin wrote:
>> its irq registers *look* like the usual set { rawstatus, status, en, dis }
>> that's their current standard ("Highlander") for peripherals. They do
>> not however *behave* like the standard set however:
>>1. status isn't always (rawstatus & enabled)
>>2. status != 0 does not always imply the irq output is asserted
>>3. some enable-bits also change the behaviour of rawstatus
>> All of these misbehaviours are unprecedented afaik.
>
> If I understand #1 correctly, you mean that bit value is different in raw vs
> status registers. I've seen some times there was a delay in the value
> reflecting the status register.
I've never seen that myself, in fact how do you even observe that? I'd
expect such propagation to require at most one cycle, and I don't expect
an irq output would get updated until it does.
> Now #2 and #3 would be crazy, do you have further notes on this?
I'll clarify what I meant.
Normally you can partition the irq bits into two types: level and event.
Level bits reflect some internal status line and cannot be manually set
or cleared. Handling these involves taking some action to clear the
underlying condition, or disabling its reporting if you no longer care.
Event bits are set by a peripheral when some event occurs, and need to
be manually cleared as part of irq handling. They can also be manually
set, e.g. for debugging.
The standard irq combiner in modern ("Highlander") TI peripherals can be
modeled roughly by the following code:
#define IRQ_BITS (EVENT_BITS | LEVEL_BITS)
// irq combiner private state
static u32 latched; // subset of EVENT_BITS
static u32 rawstatus; // subset of IRQ_BITS
static u32 enabled; // subset of IRQ_BITS
// signals from peripheral
extern u32 input; // subset of IRQ_BITS
// irq output signal
bool output;
// propagate signals
void update()
{
latched |= input & EVENT_BITS;
rawstatus = latched | input;
output = !!(rawstatus & enabled);
}
// register interface
u32 read_rawstatus() { return rawstatus; }
u32 read_status() { return rawstatus & enabled; }
u32 read_enable() { return enabled; }
u32 read_disable() { return enabled; }
void write_rawstatus(u32 x) { latched |= x & EVENT_BITS; update(); }
void write_status(u32 x) { latched &= ~(x & EVENT_BITS); update(); }
void write_enable(u32 x) { enabled |= x & IRQ_BITS; update(); }
void write_disable(u32 x) { enabled &= ~(x & IRQ_BITS); update(); }
(Some variations exist, e.g. u64 instead of u32.)
Now the omap-i2c peripheral's irq combiner looks like this at first
sight, but it violates its semantics in several ways:
#define LEVEL_BITS (BB | ((XUDF | ROVR) & ~enabled))
#define EVENT_BITS (0x7fff & ~BB)
#define IRQ_BITS EVENT_BITS // BB isn't an irq at all
void update()
{
latched |= input & EVENT_BITS;
rawstatus = (latched & ~LEVEL_BITS) | (input & LEVEL_BITS);
// note: (rawstatus & enabled) == (latched & enabled)
output = !!(rawstatus & enabled);
}
u32 read_status() { return rawstatus & (enabled | LEVEL_BITS); }
Hence:
1. level irqs are visible in status even if not enabled.
2. as direct consequence, read_status() != 0 doesn't necessarily mean
irq output is asserted.
3. when XUDF or ROVR is disabled it shows the level version in both
rawstatus and status. It is then however still latched, and the latched
version will show up when you enable it. You can set and clear the
latched bit also when it is disabled (hence invisible).
Also:
4. BB isn't even something reported via irq, what is it doing here?
5. Even though all inputs are latched, some of them are actually level
status signals from the peripheral, which means that to handle them you
have to clear the underlying condition and then additionally clear the
latch. Very convenient. XRDY behaves like this in master mode, but is
a normal event (pulsed) in slave mode. Yay for consistency!
I also have more comments on it in this thread:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/533394/1966122#1966122
> But, at least the description has been updated on Jacinto 6 device.
>
> I see all 'status' bits are write 1 to clear except for B
Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request.."
If you look more carefully the first problem is actually a bus error: [ 15.776190] Unhandled fault: external abort on non-linefetch (0x1028) at 0xf9e3e044 [ 15.825925] PC is at omap_hwmod_read+0x14/0x28 [ 15.830583] LR is at omap_rtc_wait_not_busy+0x1c/0x44 I have no idea how the kernel manages to continue after a bus error in a driver (inside local_irq_disable even), but I wouldn't be inclined to take any later errors seriously. See also the "4.8 crash on BeagleBone" thread on linux-omap. Matthijs
Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request.."
On 10 September 2016 at 01:47, Tony Lindgren wrote: > Yeah. Just disable omap_l3_smx/noc driver and you should see > a proper stack trace. With the L3 driver we're seeing the trace > for L3 error interrupt. Huh what, I see a proper stack trace in his post? I'm pretty sure omap_l3_noc doesn't even support am335x currently. Matthijs
Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states
On 8 September 2016 at 15:38, Rob Herring wrote: > Yes, in theory a device can go from disabled to okay, but that's > generally never been supported. Linux takes the simple approach of > "disabled" means ignore it. I think we'll see that change with > overlays. No need for future tense there, overlays are being used on a daily basis on the BeagleBone and have already been for years. > I don't agree. Generally, disabled means the h/w is there, but don't > use it. There may be some cases where the hardware doesn't exist for > the convenience of having a single dts, but that's the exception. Yes and no. What matters is whether "don't use it" means "you can't put it to good use" or "don't even try to reach the peripheral, bad things will happen". Right now it's used for both cases. Ideally the latter case would be removed from the kernel's view entirely. On 8 September 2016 at 16:20, Nishanth Menon wrote: > Minor point here It's not minor, it's quite crucial. > maintaining dts per paper spin is just too impossible to maintain Even if the per-spin dtsi just consists of including the common dtsi and then applying /delete-node/ per peripheral that is disabled in efuse? (or through firewalling, e.g. on HS devices) > the variations if maintained as seperate dts might infact end up being > larger in number than all the dts we have in arch/arm/boot/dts There are 813 dts files there. Even if there were a dra7xx and am57xx for every value of x (and there really isn't) you wouldn't get anywhere near there. But, fair enough, efuse bits are definitely an excellent way to get combinatorial explosion. Afaik those feature bits are readable through the control module on TI SoCs though. Assuming such a thing is the norm in SoC world maybe a "delete-if" property referencing some sort of test on register bits of a referenced syscon node might do the trick? On the cortex-A8 doing auto-detection would be a feasible alternative, by reusing the existing exception mechanism to trap synchronous aborts, but e.g. the Cortex-A15 seems to use async aborts for *every* bus error, which makes things just very awful. Matthijs
Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz
On Mon, Sep 05, 2016 at 11:16:38AM +0200, H. Nikolaus Schaller wrote:
> This helps to get 100% intensity closer to "always on".
>
> It compensates for an effect of dmtimer which at 100% still emits short
> "off" impulses and the startup-time of the DC/DC converter makes
> backlight intensity not reach full scale. The lower the PWM frequency
> is, the smaller is this effect.
Sounds to me like you're working around something that should be fixed
in the pwm-omap-dmtimer driver instead?
Looking at the (baremetal) dmtimer pwm code I wrote ages ago, which
supports fully off to fully on, I do seem to be handling both endpoints
in a special way. A rough conversion of my code into C:
// period in timer cycles
void pwm_init( volatile struct dmtimer *timer, u32 period, bool invert )
{
assert( period >= 2 );
timer->if_ctrl = 2; // reset timer, configure as non-posted
timer->reload = -period;
timer->trigger = 0;
timer->config = 0x1043 | invert << 7; // pwm initially disabled
}
// value in timer cycles, 0 <= value <= period
void pwm_set( volatile struct dmtimer *timer, u32 value )
{
if( value == 0 ) {
timer->config &= ~0x800; // disable pwm
return;
}
u32 period = -timer->reload;
if( value >= period )
timer->match = 0;
else
timer->match = value - period - 1;
timer->config |= 0x800; // enable pwm
}
At the time I used a scope to check the exact behaviour of dmtimer pwm
on a dm814x. My notes mention (when pwm enabled):
match < reload output on continuous
match == reload output on 1 cycle, off period-1 cycles
match == -2 output on period-1 cycles, off 1 cycle
match == -1 output freezes
Hope this helps
Matthijs
Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz
On 10 September 2016 at 09:08, H. Nikolaus Schaller wrote: > Reducing the PWM frequency is good by itself since it should not be > unnecessarily > fast and helps to make the PWM to "average current" translation more linear. > > The non-linear effect is that the PWM controlled DC/DC converter reacts almost > immediately to a 1->0 control transition but needs some time (ca. 0.5ms) to > recover > on a 0->1 transition. DT already allows for compensation of many non-linearities by specifying the duty cycle of each brightness increment. Though, as you observed, there's one limitation it cannot fix here: > If we just fix the PWM generator to output a steady 1 signal at 100%, we have > a > very significant change if we switch to 99%, depending on PWM frequency. Specifically the next-to-brightest step (assuming 0.5ms off-time) would be: 75% @ 500 Hz 90% @ 200 Hz 95% @ 100 Hz 96% @ 83 Hz Note that perceptually the distance to 100% might be smaller due to non-linear response of the eye. That's my experience with pwm controlled leds anyway, which may or may not apply to backlights (though with my laptop's backlight I never really have use for the distinct steps at the brightest end while those at the darkest end seem disproportionally large). > This effect becomes smaller if the PWM frequency is reduced and 83Hz seems > more > reasonable (although still a little arbitrary) than the current value. While 500Hz is perhaps a bit high, 83Hz actually seems very low to me. Searching a bit around yielded 175 Hz as common frequency for CCFL backlights and higher for LED backlights (source: http://www.tftcentral.co.uk/articles/pulse_width_modulation.htm). (I may be reacting a bit twitchy here due to having encountered dimmed LED lighting that was flickering obnoxiously for me while noone else noticed this.) Matthijs
L3 error handling (was: Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request..")
On 10 September 2016 at 15:10, Tony Lindgren wrote: > Yeah I don't think we have L3 interrupts working for am335x. It probably doesn't help that the L3 interconnect registers on the am335x aren't documented in the TRM. See below for its list of components, target IDs, address mapping, and L3 error irq routing (obtained by mostly-automated scanning/testing). The problem you mention of getting a useless traceback is indeed annoying, but on a cortex-a8 it wouldn't happen for device accesses: external aborts on device reads (and strongly-ordered reads/writes) are synchronous and taken before the irq. If you'd hook into that handler and grab/clear the corresponding L3 error to make the abort more informative then the irq will never be taken. Bus errors on device writes outside the cortex-A8 subsystem never result in an abort reported to the cpu and by the time the irq is taken the traceback may be less informative (although there's still good chance it's not far from the culprit). On the cortex-A9 I don't know what the situation is. On the cortex-A15 I don't think your advice actually helps since all bus errors seem to result in async aborts reported really ridiculously late: I've seen bus errors in a userspace process actually get reported by the L3 noc driver (complete with useless traceback), resulting in a task switch to systemd-journald to log all that spam, and only *then* the async abort was taken resulting in a perfectly innocent process getting killed with a SIGBUS. Needless to say, this is just... wrong. Matthijs
Re: L3 error handling (was: Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request..")
On Sat, Sep 10, 2016 at 04:46:49PM +0200, Matthijs van Duin wrote:
> It probably doesn't help that the L3 interconnect registers on the
> am335x aren't documented in the TRM. See below for its list of
> components, target IDs, address mapping, and L3 error irq routing
> (obtained by mostly-automated scanning/testing).
Whoops, I forgot something :)
// L3F service network
extern HostAgent host_l3f;// 0x440'00'000, id 0x00, no irq
extern TargetAgent ta_hash; // 0x440'00'200, id 0x02, irq_l3f 9
extern TargetAgent ta_aes1; // 0x440'00'300, id 0x03, irq_l3f 10
extern TargetAgent ta_ocmc; // 0x440'00'400, id 0x10, irq_l3f 2
extern TargetAgent ta_aes0; // 0x440'00'500, id 0x04, irq_l3f 11
extern TargetAgent ta_exp; // 0x440'00'600, id 0x06, irq_l3f 8
extern TargetAgent ta_edmatc0; // 0x440'00'700, id 0x07, irq_l3f 3
extern TargetAgent ta_edmatc1; // 0x440'00'800, id 0x08, irq_l3f 4
extern TargetAgent ta_edmatc2; // 0x440'00'900, id 0x09, irq_l3f 5
extern TargetAgent ta_l4hs_0; // 0x440'00'a00, id 0x05, irq_l3f 12
extern TargetAgent ta_edmacc; // 0x440'00'b00, id 0x0b, irq_l3f 6
extern TargetAgent ta_sgx; // 0x440'00'c00, id 0x0e, irq_l3f 13
extern TargetAgent ta_l3instr; // 0x440'00'd00, id 0x1f, irq_l3f 7
extern TargetAgent ta_pcie; // 0x440'00'e00, id 0x0f, irq_l3f 1
extern TargetAgent ta_emif; // 0x440'00'f00, id 0x01, irq_l3f 0
extern FlagCombiner irq_l3f;// 0x440'01'000, 14 × { app, dbg }, irq_top 0
extern FlagCombiner irq_top;// 0x440'01'100, 2 × { app, dbg }
extern Component stats0;// 0x440'02'000, size 0x800
extern Component stats1;// 0x440'03'000, size 0x1000
extern Component stats2;// 0x440'04'000, size 0x800
extern BwRegulator bwreg0; // 0x440'05'000
// L3S service network
extern HostAgent host_l3s;// 0x448'00'000, id 0x0c, no irq
extern TargetAgent ta_l4ls_0; // 0x448'00'100, id 0x11, irq_l3s 0
extern TargetAgent ta_l4ls_1; // 0x448'00'200, id 0x12, irq_l3s 1
extern TargetAgent ta_l4ls_2; // 0x448'00'300, id 0x13, irq_l3s 2
extern TargetAgent ta_l4ls_3; // 0x448'00'400, id 0x14, irq_l3s 3
extern TargetAgent ta_adc; // 0x448'00'500, id 0x0a, irq_l3s 10
extern FlagCombiner irq_l3s;// 0x448'00'600, 13 × { app, dbg }, irq_top 1
extern TargetAgent ta_gpmc; // 0x448'00'700, id 0x1e, irq_l3s 7
extern TargetAgent ta_mcasp0; // 0x448'00'800, id 0x20, irq_l3s 4
extern TargetAgent ta_mcasp1; // 0x448'00'900, id 0x21, irq_l3s 5
extern TargetAgent ta_mcasp2; // 0x448'00'a00, id 0x22, irq_l3s 6
extern TargetAgent ta_usb; // 0x448'00'b00, id 0x27, irq_l3s 9
extern TargetAgent ta_mmc2; // 0x448'00'c00, id 0x26, irq_l3s 12
extern TargetAgent ta_l4fw; // 0x448'00'd00, id 0x1b, irq_l3s 8
extern TargetAgent ta_l4wk_0; // 0x448'00'e00, id 0x0d, irq_l3s 11
extern Component stats3;// 0x448'04'000, size 0x800
l3ls ports 1-3 are just extrapolation since they aren't reachable from
the cortex-A8, the rest is verified.
I also have a list of initiators needed to identify them from L3 error
logs. I obtained it from info I found floating around and haven't much
validated it yet:
// L3 initiator ids
enum iid6_t {
I6_HASS_0 = 0x00, // Cortex-A8, 128-bit port 0 to RAM
I6_HASS_1 = 0x01, // Cortex-A8, 64-bit port 1 to peripherals
I6_DAP = 0x04, // Debug access port (AHB-AP)
I6_DFT = 0x05, // Device functional test / IEEE1500
I6_PRUSS_0 = 0x0e, // PRU core 0
I6_PRUSS_1 = 0x0f, // PRU core 1
I6_MEDIALB = 0x10, // Media local bus (automotive only)
// I6_WKUPM3 = 0x14, // Wakeup-M3 (connects to l4wk, not l3)
I6_EDMATC0_R= 0x18, // EDMA transfer controller 0, read port
I6_EDMATC0_W= 0x19, // EDMA transfer controller 0, write port
I6_EDMATC1_R= 0x1a, // EDMA transfer controller 1, read port
I6_EDMATC1_W= 0x1b, // EDMA transfer controller 1, write port
I6_EDMATC2_R= 0x1c, // EDMA transfer controller 2, read port
I6_EDMATC2_W= 0x1d, // EDMA transfer controller 2, write port
I6_SGX = 0x20, // SGX-530 graphics accelerator
I6_LCDC = 0x24, // LCD controller DMA
I6_EXP = 0x2c, // Expansion (not usable or non-existent)
I6_ETH = 0x30, // Ethernet DMA
I6_USB_DMA = 0x34, // USB subsystem DMA, data
I6_USB_QMGR = 0x35, // USB subsystem DMA, queue manager
// I6_PCIE = 0x3a, // PCIe bridge (non-existent)
I6_STATCOLL_0 = 0x3c, // L3 statistics collector 0
I6_STATCOLL_1 = 0x3d, // L3 statistics collector 1
I6_STATCOLL_2 = 0x3e, // L3 statistics collector 2
I6_STATCOLL_3 = 0x3f, // L3 statistics collector 3
};
I don't know yet to which initiator bwreg0 belongs, nor any details for
the statistics collectors.
Matthijs
Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states
On 12 September 2016 at 15:35, Tom Rini wrote: > What do you mean by "you can't put it to good use" ? Is that the case > of stuff that's say exposed via a header and could be used but isn't (ie > the cape/hat/chip/etc case) or the IP block is still OK but just not > exposed at all? > > What we're trying to address here is the case of "don't even try to > use the peripheral, bad things will happen. But please properly idle > the IP block!". I'm pretty sure IP blocks in the "don't even try" category are necessarily idled. There's no reason they wouldn't be. The hwmod infrastructure generally tries to access the sysconfig register located in the IP block address space itself. If you try to do that with a peripheral that's efused out you'll get a bus error. Matthijs
