Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote: > +- compatible : shall be one of "ti,dm814-adpll-s-clock" or > + "ti,dm814-adpll-j-clock" depending on the type of the ADPLL There's still a j -> lj you missed. Also, since the device series almost always referred to as dm814x, any

Re: [PATCH 1/3] ARM: OMAP2+: Fix SoC detection for dra62x j5-eco

On 4 December 2015 at 00:11, Tony Lindgren wrote: > We can boot dra62x j5-eco using the dm814x code as the clocks and > devices are mapped in the device tree. The dra62x is also known > as jacinto 5. I'm pretty sure the "eco" in the name isn't optional. As far as I know:

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

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

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

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.

Re: Minimal support for dm814x

On 18 November 2015 at 09:26, Delio Brignoli wrote: >> This works in principle, but both minimizing the DCO and (often >> needlessly) using the fractional multiplier seem like recipes to >> maximize the clock jitter. Mind you, I don't know how much jitter >> we’re

Re: Minimal support for dm814x

On 13 November 2015 at 15:52, Tony Lindgren wrote: > I think this is the most recent TI git repo for dm81xx changes: > > http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary Yeah, although I usually prefer to look at the linux-ipnc-rdk-dm81xx.git and

Re: Minimal support for dm814x

On 13 November 2015 at 08:14, Matthijs van Duin <matthijsvand...@gmail.com> wrote: > It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL Never mind, wasn't paying attention and managed to overlook that google had found me the u-boot tree instead of the kernel tree I

Re: Minimal support for dm814x

On 11 November 2015 at 18:40, Tony Lindgren wrote: > Well we do first try to set the rate using the divider only at least for > drivers/clk/ti/fapll.c used on dm816x. I'm thinking about doing a similar > driver for the dm814x adpll where we have a PLL and separate output clocks

Re: Minimal support for dm814x

On 12 November 2015 at 18:41, Tony Lindgren wrote: > Does the old TI kernel tree driver correctly handle that? It seems this is how the old TI kernel handles them: http://goo.gl/3I3OEL -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a

Re: Minimal support for dm814x

On 9 November 2015 at 16:06, Tony Lindgren wrote: > The PLL support is still missing, so it relies on the bootloader > configured PLL values for now. I'm hoping to post PLL support patches over > next few weeks and then we can have that and more devices working for v4.5. Ah,

Re: Minimal support for dm814x

On 10 November 2015 at 11:23, Delio Brignoli wrote: > are you aware of section 2.1.2 of ... I am. It seems that the digital PLLs tend to produce an asymmetrical clock in general hence you need an even postdivider to get a 50% duty cycle. DPLL-S however already has an

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

Re: [PATCH] ARM: dts: am335x-boneblack: disable RTC-only sleep

. Reported-by: Matthijs van Duin matthijsvand...@gmail.com Tested-by: Matthijs van Duin matthijsvand...@gmail.com Signed-off-by: Robert Nelson robertcnel...@gmail.com Cc: Tony Lindgren t...@atomide.com Cc: Felipe Balbi ba...@ti.com Cc: Johan Hovold jo...@kernel.org [Matthijs van Duin: added

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 t...@atomide.com 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

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 t...@atomide.com 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

Re: [PATCH] ARM: dts: am335x-boneblack: disable RTC-only sleep

Sorry for the late response, I only just noticed this since I wasn't CC'd. This fix was not ever Reported-By or Tested-By me as it claims. It is in fact wrong: rtc { system-power-controller; } needs to be present for every variety of beaglebone (more generally every design with a TPS65217 whose

Re: [PATCH] ARM: dts: am335x-boneblack: disable RTC-only sleep

contains more explanation, I made the commit message more concise. Apologies for the attachment (inline text would get fucked up by gmail) From 4278ecc32e886d2e83bc486e6409d8f6df82a0d1 Mon Sep 17 00:00:00 2001 From: Matthijs van Duin matthijsvand...@gmail.com Date: Mon, 1 Jun 2015 06:56:24 +0200 Subject

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 t...@atomide.com 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

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 t...@atomide.com 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,

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 matthijsvand...@gmail.com 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

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 t...@atomide.com 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

Re: ARM errata 430973 on multi platform kernels

On 23 April 2015 at 12:25, Russell King - ARM Linux li...@arm.linux.org.uk wrote: And you can't detect whether you're running in secure mode or not. If not, you get an undefined instruction exception, which you could trap. This may not be convenient, but can't detect is an overstatement.

Re: ARM errata 430973 on multi platform kernels

On 10 April 2015 at 00:37, Grazvydas Ignotas nota...@gmail.com wrote: May I ask how do you perform the smc call? A point worth mentioning is that TI advises that r1-r4 may be clobbered in general, and at least on GP dm814x and am335x devices r4 is in fact clobbered, even though it is normally a

Re: am335x crypto module clocks

On 13 April 2015 at 12:27, Tero Kristo t-kri...@ti.com wrote: pka/rng/des is using l4ls_gclk. Does any instance of subarctic actually have a working DES accelerator? Looking at the L4LS memory map, the only plausible location for it would be 0x48315000 (sec context) / 0x48316000 (pub context),

Re: ARM errata 430973 on multi platform kernels

* Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com [150406 10:15]: Why custom function, if IBE bit is zero, BTB invalidate instruction is a NOP. Do you think that mcr p15, 0, r2, c7, c5, 6 executed as a NOP will put so much overhead, that it deserves a custom function? Executing them as nop is

Re: ARM errata 430973 on multi platform kernels

On 7 April 2015 at 04:23, Tony Lindgren t...@atomide.com wrote: Oops, sorry user error.. I was trying to clear IBE as a banked register like L2 enable bit and of course it did not get cleared.. Clearing it with a smc call really clears it. And in that case my test case seems to work reliably

Re: ARM errata 430973 on multi platform kernels

Cortex-A8 errata doc states in its workaround for erratum 430973: By default, the BTB Invalidate instruction is treated as a NOP on Cortex-A8. However, it is possible to enable the BTB Invalidate instruction such that it actually does a full invalidate of the BTB by setting the IBE bit (bit 6)

Re: ARM errata 430973 on multi platform kernels

On 5 April 2015 at 18:50, Matthijs van Duin matthijsvand...@gmail.com wrote: MRC I mean MCR of course -- 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: ARM errata 430973 on multi platform kernels

On 5 April 2015 at 09:23, Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com wrote: Though I wonder why SMC is needed to write ACR on non-HS devices. A simple MRC should suffice, unless I miss something. Public-world access to ACR varies per bit: bit 1 (L2EN) is documented as banked, but at least on

am335x crypto module clocks

Hi all, To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently lists the functional clock of the AES accelerator and other crypto modules to be the (max 26 MHz) main osc. This struck me as rather unlikely, since the AES module is clocked much higher on other devices, and such a slow

Re: ARM errata 430973 on multi platform kernels

On 4 April 2015 at 00:52, Tony Lindgren t...@atomide.com wrote: Right, it affects n900 for sure. My point is that it also seems to affect 37xx versions not listed to suffer from this issue. They shouldn't... erratum 430973 only affected Cortex-A8 r1, and the dm37xx should have an r3p2 right? A

Re: patch phy: Add a driver for dm816x USB PHY added to linux-phy tree

On 26 March 2015 at 00:36, Kishon Vijay Abraham I kis...@ti.com wrote: Let me know if you find any problems with this patch. I spotted a minor issue in drivers/phy/Kconfig: + Enable this for dm81xx USB to work. This should say dm816x instead. Matthijs -- To unsubscribe from this

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 17 March 2015 at 03:19, Tony Lindgren t...@atomide.com 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

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

And we also need to populate the tables along the lines of 27b7d5f3cc49 (bus: omap_l3_noc: Add AM4372 interconnect error data). I think intercon data should be in DT rather than some hardcoded table. Do the below ranges match your JTAG results? Yup. Based a memory dump I had done earlier,

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

Matthijs van Duin matthijsvand...@gmail.com wrote: 44400500 target 11 vcp 44800100 target 18 vlynq ? scrap these guesses: I don't think Netra has a vcp module, and I had only filled in vlynq based on it being the only remaining target NIU. Once the memory ranges for the targets have been

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 16 March 2015 at 17:49, Tony Lindgren t...@atomide.com wrote: * Matthijs van Duin matthijsvand...@gmail.com [150314 14:04]: On 13 March 2015 at 20:30, Tony Lindgren t...@atomide.com wrote: Hmm OK have to check that. It could also be that dm816x documentation is copy-paste from da850

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 13 March 2015 at 20:30, Tony Lindgren t...@atomide.com 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

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

Re: Enabling DBGEN signal in GP OMAP3

On 1 March 2015 at 01:03, Grazvydas Ignotas nota...@gmail.com wrote: On Thu, Feb 26, 2015 at 5:14 AM, Matthijs van Duin wrote: If you want guaranteed reliability, modify tck_pulse() to insert aforementioned barrier + an actual delay at all three points where I put comments about them. usleep

Re: Enabling DBGEN signal in GP OMAP3

On 26 February 2015 at 02:09, Grazvydas Ignotas nota...@gmail.com wrote: And hey, it worked too with your code modified to use USB Blaster in it's bitbang mode over libftdi. This setup also works with openocd, but somewhat unreliably (only occasionally gets through init, often gets register

Re: Enabling DBGEN signal in GP OMAP3

On 26 February 2015 at 02:09, Grazvydas Ignotas nota...@gmail.com wrote: I've finally got rid of nTRST pulldown (haven't connected TDO though), created hw-omap3.{h,cc}, but couldn't get it to do anything, until it came to my mind that you may be running ARM on your BBB slower that 1GHz that

Re: Enabling DBGEN signal in GP OMAP3

At least on the am335x, the trick actually works! I have a working demo which configures ICEPick registers and even performs transactions on the debug interconnect. I've been lazy and imported a bunch of files from my baremetal projects so I could easily mess with the hardware, rudely bypassing

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 18 February 2015 at 22:14, Pali Rohár pali.ro...@gmail.com wrote: Can you help us with above problem? How to catch external abort on non-linefetch in kernel driver and prevent kernel panic? Actually it's a synchronous bus error that you want to catch, which however is misreported by linux as

Re: Enabling DBGEN signal in GP OMAP3

On 19 February 2015 at 03:16, Grazvydas Ignotas nota...@gmail.com wrote: It turns out 050, 054 and 058 (but only them) are actually documented in dm3730 manual and are part of Emulation Pin Manager. 058 works as you (and the manual) describe, however claiming and enabling EPM registers still

Re: Enabling DBGEN signal in GP OMAP3

On 18 February 2015 at 15:54, Tony Lindgren t...@atomide.com wrote: From memory.. I believe the issue was that for anything needing to set the counter and rely on the counter interrupt things would fail as the counter interrupts would not always happen. Correct, but the interrupt is just used

Re: Enabling DBGEN signal in GP OMAP3

On 18 February 2015 at 00:37, Grazvydas Ignotas wrote: On Mon, Feb 16, 2015 at 8:43 PM, Matthijs van Duin wrote: A dump of all non-zero registers in DAPCTL (the 4KB block at 0x5401d000) might be interesting. Attached OK, nice. I like peripherals which fault accesses to non-existent

Re: Enabling DBGEN signal in GP OMAP3

I don't have an OMAP3 to play with, but I wouldn't be surprised if a debug-enable bit also needs to be set in an ICEPick control register. On omap4-generation targets with ICEPick-D (e.g. dm81xx and am335x) the DBGEN signal is in fact fully controlled via ICEPick. This really sucks since without

Re: Enabling DBGEN signal in GP OMAP3

On 15 February 2015 at 22:30, Grazvydas Ignotas nota...@gmail.com wrote: The DBGEM signal on the Cortex-A8 is driven by setting bit 13 at address 0x5401 D030 in the DAP-APB address space. The register is apparently, for some reason, called DAP_PC_FER according to some notes of mine (I have no

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 11 February 2015 at 13:39, Pali Rohár pali.ro...@gmail.com wrote: Anyhow, since checking the firewalls/APs to see if you have permission will probably only get you yet another fault if things are walled off, the robust way of dealing with this sort of situation is by probing the device with

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

On 2 February 2015 at 18:44, Tony Lindgren t...@atomide.com wrote: * Matthijs van Duin matthijsvand...@gmail.com [150128 13:46]: On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote: I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired to 32KiHz by looking

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On Sunday 08 December 2013 00:22:06 Tony Lindgren wrote: * Sebastian Reichel s...@ring0.de [131207 15:04]: On Sat, Dec 07, 2013 at 01:11:37PM -0800, Tony Lindgren wrote: I asked Pali to send me his copy of the updated NOLO bootloader, so that I can test this. I just checked the omap

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 31 January 2015 at 12:34, Pali Rohár pali.ro...@gmail.com wrote: [ 172.923553] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f87028 [ 172.930664] In-band Error seen by MPU at address 0 Also, why is this error so uninformative? A synchronous abort should at least

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 31 January 2015 at 20:06, Pali Rohár pali.ro...@gmail.com wrote: Just to note that above error output is from device where is signed X-Loader which *enable* omap aes support. So it looks like it is not possible to dump registers which should tell you if kernel has permission or not (in L3

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

I just noticed the dm816x.dtsi says: ocp { compatible = ti,omap3-l3-smx, simple-bus; This is incorrect: the DM81xx (and siblings like the AM335x) use Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not SonicsMX. (In general everything on the DM81xx seems to be

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

On 26 January 2015 at 16:58, Tony Lindgren t...@atomide.com wrote: See earlier I was assuming copy paste issues from dm814x to dm816x Ahh, you thought the 816x was 814x-derived... yes I can imagine that will have led to some confusion. I'm pretty sure I verified the that the audio_pll_clk1 is

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

On 23 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote: That's interesting info thanks :) Yeah it seems dm814x was done after dm816x and that clears at least some of the clockdomain confusion that I though was TRM copy-paste issue. Well it is in some sense still a copy-paste issue

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

On 19 January 2015 at 18:29, Tony Lindgren t...@atomide.com wrote: Hmm I sort of got the idea that dm814x and dm816x were done about the same time. Are you saying dm814x was actually done after dm816x? Well, it's hard to come up with an alternate explanation of netra's FAPLLs showing up in the

Re: [PATCH 1/7] ARM: OMAP2+: Remove unused ti81xx platform init code

--- a/arch/arm/mach-omap2/usb-musb.c +++ b/arch/arm/mach-omap2/usb-musb.c @@ -82,16 +82,8 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data) musb_plat.mode = board_data-mode; musb_plat.extvbus = board_data-extvbus; - if (soc_is_am35xx()) { Was it intentional

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

On 17 January 2015 at 17:47, Tony Lindgren t...@atomide.com wrote: Also looks like the PULL_ENA bit is inverted on dm816x like on am33xx Yes, ditto on dm814x but there things get even more interesting: It has the same four config bits as am335x but moved them to bits 16-19, while bits 0-7

Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

On 17 January 2015 at 19:14, Tony Lindgren t...@atomide.com wrote: Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0] bits for MUXMODE instead of just bits [2:0]? However, the datasheet's table of possible mux modes per pin has as column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40,