Re: [patch-net-next v3 1/2] net: ethernet: cpsw: unroll IRQ request loop
From: Felipe Balbi Date: Fri, 16 Jan 2015 10:11:11 -0600 > This patch is in preparation for a nicer IRQ > handling scheme where we use different IRQ > handlers for each IRQ line (as it should be). > > Later, we will also drop IRQs offset 0 and 3 > because they are always disabled in this driver. > > Signed-off-by: Felipe Balbi Applied. -- 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-net-next v3 2/2] net: ethernet: cpsw: don't requests IRQs we don't use
From: Felipe Balbi Date: Fri, 16 Jan 2015 10:11:12 -0600 > CPSW never uses RX_THRESHOLD or MISC interrupts. In > fact, they are always kept masked in their appropriate > IRQ Enable register. > > Instead of allocating an IRQ that never fires, it's best > to remove that code altogether and let future patches > implement it if anybody needs those. > > Signed-off-by: Felipe Balbi Applied. -- 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] ARM: dts: Add minimal support for dm8168-evm
On 17 January 2015 at 19:14, Tony Lindgren 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, 0x80. (mode 0, called "safe mode" is mentioned separately) For compatibility sake I'm personally more inclined to consider them modes 0-7 with "safe mode" being -1. Oh, and I just remembered: while 811x is mostly compatible with 814x, it has up to 12 mux modes per pin. So replace "byte-write" by "u16-write" in my previous post ;-) >> It also means you can change mode with a u16-write to avoid touching >> the upper bits > > Maybe that's why some bits got shifted :) Yes, in general bitfields seem to be grouped into separate bytes in quite a few places where it may be convenient to take advantage of the fact that both PRCM and the Control module are byte-addressable to avoid having to do a read-modify-update. (For example the omap4/5 standard layout for CLKCTRL puts modulemode in byte 0, optional fclks in byte 1, and any mux/div config the module may have in the upper bytes. Only the am335x violates this rule.) >> The overall control module layout is actually compatible across the >> whole happy family > > Got any generic naming in mind for the helper macro we could use? I've already been pondering what to call this family, since architecturally they do very clearly form a fairly close family related to, but also clearly distinct from, the omap4/5 line. As you may notice from my spreadsheet I already generally prefer to use their names (Netra, Centaurus, Subarctic, Aegis), both because names are rather more memorable and distinguishable for humans than 4-digit numbers and because each actually has a flurry of wildly different part codes depending on which subsystems happen to fail the factory test and get disabled (which may of course be a big deal featurewise but is rather irrelevant to the kernel). Still leaves four names to unify... I may be biased but I'm leaning towards "Centauroid": Centaurus (814x) seems to have a fairly central position, being memory-map compatible with the there other members (i.e. no subsystem/peripheral of Centaurus overlaps a different one of another device), while the same is not true between Netra (816x) and subarctic (335x). I suspect this may be because Centaurus and Netra form a single product line (DM81xx) iin one market segment (video) while Centaurus and Subarctic form a single product line (DRA6xx) in another market segment (automotive). > Cool, that certainly helps. To me it looks dm814x needs it's own > clock driver for the source clocks, but after that the dividers > are similar to dm816x and am33xx. Have not looked at the am814x > beyond that though. dm814x you mean... the downfeatured Sitara version got called am387x, naturally. ;-) The biggest architectural differences between three chips are indeed in PRCM, where each member has its own peculiarities: Netra and Centaurus both have the simple but clean omap4-subset PRCM. No fancy auto-management by hardware but at least a clean well-organised interface, with the biggest blemish being the register-swap in PRM_SGX. (Subarctic's PRCM is of course shocking in contrast, being organized by "sort -R", incompatibility with the omap4/5 register layouts, and a seemingly endless supply of novel ways of being inconsistent.) Netra however has the FAPLL experiment, which apparently wasn't a success so while Centaurus retained much of the clock tree it reverted to using normal PLLs by replacing the FAPLLs with its PLL subsystem containing additional clock muxes to sort of glue it onto the existing clock tree, making the clock tree a bit messier. (Especially older versions of the TRM were very confusing to those unfamiliar with this Netra-heritage since FAPLL names were still all over the place.) In line with the "fully software managed" tradition, it seems to wire *all* control/status signals of the PLLs directly into registers. They can be slightly fickle (and mucking up the MPU PLL can leave you pretty screwed, especially since the watchdog reset doesn't reset the PLLs). Also important: Centaurus has very similar Ethernet subsystem to that of subarctic, though some components are a slightly older minor revision. In violation of what a "minor revision" normally means, they are however software-incompatible thanks to moving blocks of registers around to different offsets, and some per-port settings became global or vice versa. This however seems to be a tradition for the 3-port gigabit switch subsystem: out of curiosity I examined the ones in other TI SoCs, and it turns out that literally *all* of them have different, incompatible register layouts (sometimes also extending to the switch table entries and/or DMA descriptors). Other than this, the subsystems and peripherals are mostly familiar omap4-generation stuff, but with a st
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
* Matthijs van Duin [150117 09:54]: > On 17 January 2015 at 17:47, Tony Lindgren 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 contains 1 << mode. The benefit is that you can > also select no mode at all (high-Z or just the pull if enabled) and > this is in fact the default, though I'm curious what would happen if > multiple bits are set (though not curious enough to risk my hardware > :P ). Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0] bits for MUXMODE instead of just bits [2:0]? > It also means you can change mode with a byte-write to avoid touching > the upper bits, which is nice especially since slew is preconfigured > per pin to match I/O timings and you're supposed to never change it > (after fixing the ones ROM messed up due to bugs). Also on rev 2.x > silicon you're not allowed to disable the receiver if using 3.3V I/O. Maybe that's why some bits got shifted :) > > +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) > > (val) > > #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > > #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > > The overall control module layout is actually compatible across the > whole happy family; basically any register they have in common is at > the same offset (with notable exception of ADC and eCAP event muxes on > am335x versus c6a811x/dra62x, but the latter is a semi-mythical device > anyway, not even a product brief in circulation). They often even have > the same semantics, though padconf shows this isn't always true > unfortunately. Got any generic naming in mind for the helper macro we could use? > A similar thing is true for the overall device memory map actually: > https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view Cool, that certainly helps. To me it looks dm814x needs it's own clock driver for the source clocks, but after that the dividers are similar to dm816x and am33xx. Have not looked at the am814x beyond that though. 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: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
On 17 January 2015 at 17:47, Tony Lindgren 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 contains 1 << mode. The benefit is that you can also select no mode at all (high-Z or just the pull if enabled) and this is in fact the default, though I'm curious what would happen if multiple bits are set (though not curious enough to risk my hardware :P ). It also means you can change mode with a byte-write to avoid touching the upper bits, which is nice especially since slew is preconfigured per pin to match I/O timings and you're supposed to never change it (after fixing the ones ROM messed up due to bugs). Also on rev 2.x silicon you're not allowed to disable the receiver if using 3.3V I/O. > +#define DM816X_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) > #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) The overall control module layout is actually compatible across the whole happy family; basically any register they have in common is at the same offset (with notable exception of ADC and eCAP event muxes on am335x versus c6a811x/dra62x, but the latter is a semi-mythical device anyway, not even a product brief in circulation). They often even have the same semantics, though padconf shows this isn't always true unfortunately. A similar thing is true for the overall device memory map actually: https://docs.google.com/spreadsheets/d/1hRgpmJ-4Yeojyl8XPO9n3IoYSWKPkg6oRnEvdfV_RaM/view -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: Work around hardcoded interrupts
* Marc Zyngier [150117 02:24]: > Commit 9a1091ef0017 (irqchip: gic: Support hierarchy irq domain) > changed the GIC driver to use a non-legacy IRQ domain on DT > platforms. This patch assumes that DT-driven systems are getting > all of their interrupts from device tree. > > Turns out that OMAP has quite a few hidden gems, and still uses > hardcoded interrupts despite having fairly complete DTs. > > This patch attempts to work around these by offering a translation > method that can be called directly from the hwmod code, if present. > The same hack is sprinkled over PRCM and TWL. > > It isn't pretty, but it seems to do the job without having to add > more hacks to the interrupt controller code. > > Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432). > > Signed-off-by: Marc Zyngier > --- > >From v1: > - OMAP4 can either get the PRM interrupt from hwmod or from device tree. > In the latter case, remove the xlate_irq method. OK looks good to me. Let's wait for Nishanth to run his tests one more time. BTW, looks like we already have the omap4 prm interrupt in the omap4.dtsi file but removing the legacy code would add the "old DT with newer kernel" issues to the mixture.. So best leave that for later clean up patches and keep this fix as is. 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Pali Rohár [150117 09:32]: > On Saturday 17 January 2015 18:04:11 Tony Lindgren wrote: > > * Pali Rohár [150117 01:21]: > > > Hello, after playing with aes and non-aes version of > > > bootloaders I found out that code which configure L3 > > > firewall must be in signed X-Loader part. So probably we > > > cannot change configuration at runtime... > > > > > > Tony, > > > any idea how to dump L3_PM_ADDR_MATCH_* registers from > > > userspace or from kernel? Now I have configured one N900 > > > with original Nokia X-Loader (where loading omap aes driver > > > cause kernel crash) and one N900 with aes X-Loader (where > > > loading omap aes driver is working). > > > > Hmm maybe give the omapconf too a try? It's at: > > > > https://github.com/omapconf/omapconf > > > > That uses /dev/mem from userspace, then you can just ioremap > > them in the kernel code if you need to do something during > > runtime. Probably best to access them with a syscon mapping > > from the aes driver. > > > > Regards, > > > > Tony > > https://github.com/omapconf/omapconf/wiki > > Legacy TI OMAP platforms (OMAP[1-2-3]) are not supported. Oh OK. Well at least you can look at the code if you want to do it from the user space :) 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Saturday 17 January 2015 18:04:11 Tony Lindgren wrote: > * Pali Rohár [150117 01:21]: > > Hello, after playing with aes and non-aes version of > > bootloaders I found out that code which configure L3 > > firewall must be in signed X-Loader part. So probably we > > cannot change configuration at runtime... > > > > Tony, > > any idea how to dump L3_PM_ADDR_MATCH_* registers from > > userspace or from kernel? Now I have configured one N900 > > with original Nokia X-Loader (where loading omap aes driver > > cause kernel crash) and one N900 with aes X-Loader (where > > loading omap aes driver is working). > > Hmm maybe give the omapconf too a try? It's at: > > https://github.com/omapconf/omapconf > > That uses /dev/mem from userspace, then you can just ioremap > them in the kernel code if you need to do something during > runtime. Probably best to access them with a syscon mapping > from the aes driver. > > Regards, > > Tony https://github.com/omapconf/omapconf/wiki Legacy TI OMAP platforms (OMAP[1-2-3]) are not supported. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Pali Rohár [150117 01:21]: > > Hello, after playing with aes and non-aes version of bootloaders > I found out that code which configure L3 firewall must be in > signed X-Loader part. So probably we cannot change configuration > at runtime... > > Tony, > any idea how to dump L3_PM_ADDR_MATCH_* registers from userspace > or from kernel? Now I have configured one N900 with original > Nokia X-Loader (where loading omap aes driver cause kernel crash) > and one N900 with aes X-Loader (where loading omap aes driver is > working). Hmm maybe give the omapconf too a try? It's at: https://github.com/omapconf/omapconf That uses /dev/mem from userspace, then you can just ioremap them in the kernel code if you need to do something during runtime. Probably best to access them with a syscon mapping from the aes driver. 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: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
* Tony Lindgren [150113 15:44]:
> This allows booting the device with basic functionality.
>
> Note that at least on my revision c board the DDR3 does
> not seem to work properly and only some of the memory
> can be reliably used.
>
> Also, the mainline u-boot does not seem to properly
> initialize the ethernet, so I've been using the old TI
> u-boot at:
>
> http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Here's this one updated with spi-nor detected and a minimal
pinctrl-single configuration. No partition info yet configured
though. Also looks like the PULL_ENA bit is inverted on dm816x
like on am33xx so at some point we probably want to have
a arch/arm/boot/dts/include/dt-bindings/pinctrl/dm816x.h.
Regards,
Tony
8< -
From: Tony Lindgren
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add minimal support for dm8168-evm
This allows booting the device with basic functionality.
Note that at least on my revision c board the DDR3 does
not seem to work properly and only some of the memory
can be reliably used.
Also, the mainline u-boot does not seem to properly
initialize the ethernet, so I've been using the old TI
u-boot at:
http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary
Cc: Brian Hutchinson
Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += am3517-craneboard.dtb \
omap3-sbc-t3730.dtb \
omap3-thunder.dtb \
omap3-zoom3.dtb
+dtb-$(CONFIG_SOC_TI81XX) += dm8168-evm.dtb
dtb-$(CONFIG_SOC_AM33XX) += am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
new file mode 100644
index 000..857d028
--- /dev/null
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -0,0 +1,129 @@
+/*
+ * 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 "dm816x.dtsi"
+
+/ {
+ model = "DM8168 EVM";
+ compatible = "ti,dm8168-evm", "ti,dm8168";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x4000/* 1 GB */
+ 0xc000 0x4000>; /* 1 GB */
+ };
+
+ /* FDC6331L controlled by SD_POW pin */
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmcsd_fixed";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+&dm816x_pinmux {
+ mcspi1_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins = <
+ DM816X_IOPAD(0x0a94, PIN_INPUT | MUX_MODE0) /*
SPI_SCLK */
+ DM816X_IOPAD(0x0a98, PIN_OUTPUT | MUX_MODE0)/*
SPI_SCS0 */
+ DM816X_IOPAD(0x0aa8, PIN_INPUT | MUX_MODE0) /*
SPI_D0 */
+ DM816X_IOPAD(0x0aac, PIN_INPUT | MUX_MODE0) /*
SPI_D1 */
+ >;
+ };
+};
+
+&i2c1 {
+ extgpio0: pcf8575@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&i2c2 {
+ extgpio1: pcf8575@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&gpmc {
+ ranges = <0 0 0x0400 0x0100>; /* CS0: 16MB for NAND */
+
+ nand@0,0 {
+ linux,mtd-name= "micron,mt29f2g16aadwp";
+ reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,nand-ecc-opt = "bch8";
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-on-ns = <0>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ partition@0 {
+ label =
Re: [PATCH 2/4] ARM: dts: Add basic dm816x device tree configuration
* Tony Lindgren [150115 15:05]:
>
> For reference, the devices I've confirmed to work so far are:
>
> - intc
> - timers
> - gpmc
> - i2c
> - ethernet and mdio
> - mmc
> - edma
> - uart
>
> Updated patch below with the mailbox fixed.
Got the spi working too. The it needs to be compatible with
ti,omap4-mcspi with four chip selects. Updated patch below.
Also added the pinctrl-single entry.
Regards,
Tony
8< --
From: Tony Lindgren
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: dts: Add basic dm816x device tree configuration
Similar to other omap variants, let's add dm816x support.
Note that this is based on generated data from the
TI81XX-LINUX-PSP-04.04.00.02 patches published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
I've verified the basic functionality, but have not been
able to test all the devices on dm8168-evm.
Cc: Brian Hutchinson
Signed-off-by: Tony Lindgren
--- /dev/null
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -0,0 +1,386 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "ti,dm816";
+ interrupt-parent = <&intc>;
+
+ aliases {
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+
+ /*
+* The soc node represents the soc top level view. It is used for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap3-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ dm816x_pinmux: pinmux@44e10800 {
+ compatible = "pinctrl-single";
+ reg = <0x48140800 0x50a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0xf>;
+ };
+
+ /*
+* XXX: Use a flat representation of the dm816x interconnect.
+* The real dm816x interconnect network is quite complex. Since
+* it will not bring real advantage to represent that in DT
+* for the moment, just use a fake OCP bus entry to represent
+* the whole bus hierarchy.
+*/
+ ocp {
+ compatible = "ti,omap3-l3-smx", "simple-bus";
+ reg = <0x4400 0x1>;
+ interrupts = <9 10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ prcm: prcm@4818 {
+ compatible = "ti,dm816-prcm";
+ reg = <0x4818 0x4000>;
+
+ prcm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ prcm_clockdomains: clockdomains {
+ };
+ };
+
+ scrm: scrm@4814 {
+ compatible = "ti,dm816-scrm";
+ reg = <0x4814 0x21000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x4814 0x21000>;
+
+ scrm_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ scrm_clockdomains: clockdomains {
+ };
+ };
+
+ cm: syscon@44e1 {
+ compatible = "ti,am33xx-controlmodule", "syscon";
+ reg = <0x44e1 0x800>;
+ };
+
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2", "tptc3";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x40>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ };
+
+ elm: elm@4808 {
+
Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support
* Tony Lindgren [150114 11:49]: > * Tony Lindgren [150113 15:29]: > > Add minimal hwmod support that works at least on dm8168. This > > is based on the code in the earlier TI CDP tree, and an earlier > > patch by Aida Mynzhasova . > > > > I've set up things to work pretty much the same way as for > > am33xx. We are basically using cm33xx.c with a different set > > of clocks and clockdomains. > > > > This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches > > published at: > > > > http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html > > > > Cc: Aida Mynzhasova > > Cc: Brian Hutchinson > > Cc: Paul Walmsley > > Signed-off-by: Tony Lindgren > > --- > > arch/arm/mach-omap2/Makefile |1 + > > arch/arm/mach-omap2/io.c |8 +- > > arch/arm/mach-omap2/omap_hwmod.c |2 +- > > arch/arm/mach-omap2/omap_hwmod.h |1 + > > arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 1025 > > > > 5 files changed, 1034 insertions(+), 3 deletions(-) > > create mode 100644 arch/arm/mach-omap2/omap_hwmod_81xx_data.c > > > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > > index 352873c..926bc39 100644 > > --- a/arch/arm/mach-omap2/Makefile > > +++ b/arch/arm/mach-omap2/Makefile > > @@ -226,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX)+= > > omap_hwmod_33xx_43xx_ipblock_data.o > > obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o > > obj-$(CONFIG_SOC_AM43XX) += > > omap_hwmod_33xx_43xx_interconnect_data.o > > obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o > > +obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o > > obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o > > obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o > > obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o > > Looks like the Makefile needs the following addition for make randconfig > builds to work properly. And the sysc and syss offsets for mcspi1 need 0x100 added to them for it to work, like on am33xx. Updated patch below. Regards, Tony 8< -- From: Tony Lindgren Date: Wed, 14 Jan 2015 17:45:22 -0800 Subject: [PATCH] ARM: OMAP2+: Add dm816x hwmod support Add minimal hwmod support that works at least on dm8168. This is based on the code in the earlier TI CDP tree, and an earlier patch by Aida Mynzhasova . I've set up things to work pretty much the same way as for am33xx. We are basically using cm33xx.c with a different set of clocks and clockdomains. This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches published at: http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html Cc: Aida Mynzhasova Cc: Brian Hutchinson Cc: Paul Walmsley Signed-off-by: Tony Lindgren --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common) am33xx-43xx-prcm-common+= prm33xx.o cm33xx.o +obj-$(CONFIG_SOC_TI81XX) += $(am33xx-43xx-prcm-common) obj-$(CONFIG_SOC_AM33XX) += $(am33xx-43xx-prcm-common) obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) \ $(am33xx-43xx-prcm-common) @@ -226,6 +227,7 @@ obj-$(CONFIG_SOC_AM33XX)+= omap_hwmod_33xx_43xx_ipblock_data.o obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_interconnect_data.o obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o +obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -502,10 +502,12 @@ void __init ti814x_init_early(void) omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL); omap3xxx_check_revision(); ti81xx_check_features(); + am33xx_prm_init(); + am33xx_cm_init(); omap3xxx_voltagedomains_init(); omap3xxx_powerdomains_init(); ti81xx_clockdomains_init(); - omap3xxx_hwmod_init(); + ti81xx_hwmod_init(); omap_hwmod_init_postsetup(); if (of_have_populated_dt()) omap_clk_soc_init = ti81xx_dt_clk_init; @@ -521,10 +523,12 @@ void __init ti816x_init_early(void) omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL); omap3xxx_check_revision(); ti81xx_check_features(); + am33xx_prm_init()
[PATCH v2] ARM: OMAP: Work around hardcoded interrupts
Commit 9a1091ef0017 (irqchip: gic: Support hierarchy irq domain)
changed the GIC driver to use a non-legacy IRQ domain on DT
platforms. This patch assumes that DT-driven systems are getting
all of their interrupts from device tree.
Turns out that OMAP has quite a few hidden gems, and still uses
hardcoded interrupts despite having fairly complete DTs.
This patch attempts to work around these by offering a translation
method that can be called directly from the hwmod code, if present.
The same hack is sprinkled over PRCM and TWL.
It isn't pretty, but it seems to do the job without having to add
more hacks to the interrupt controller code.
Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
Signed-off-by: Marc Zyngier
---
>From v1:
- OMAP4 can either get the PRM interrupt from hwmod or from device tree.
In the latter case, remove the xlate_irq method.
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/omap4-common.c | 32 ++
arch/arm/mach-omap2/omap_hwmod.c | 10 --
arch/arm/mach-omap2/omap_hwmod.h | 1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 5 +
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 1 +
arch/arm/mach-omap2/prcm-common.h | 1 +
arch/arm/mach-omap2/prm44xx.c | 5 -
arch/arm/mach-omap2/prm_common.c | 14 +++--
arch/arm/mach-omap2/twl-common.c | 5 -
10 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 377eea8..b664494 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -211,6 +211,7 @@ extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
extern struct device *omap4_get_dsp_device(void);
+unsigned int omap4_xlate_irq(unsigned int hwirq);
void omap_gic_of_init(void);
#ifdef CONFIG_CACHE_L2X0
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index b7cb44a..cc30e49 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -256,6 +256,38 @@ static int __init omap4_sar_ram_init(void)
}
omap_early_initcall(omap4_sar_ram_init);
+static struct of_device_id gic_match[] = {
+ { .compatible = "arm,cortex-a9-gic", },
+ { .compatible = "arm,cortex-a15-gic", },
+ { },
+};
+
+static struct device_node *gic_node;
+
+unsigned int omap4_xlate_irq(unsigned int hwirq)
+{
+ struct of_phandle_args irq_data;
+ unsigned int irq;
+
+ if (!gic_node)
+ gic_node = of_find_matching_node(NULL, gic_match);
+
+ if (WARN_ON(!gic_node))
+ return hwirq;
+
+ irq_data.np = gic_node;
+ irq_data.args_count = 3;
+ irq_data.args[0] = 0;
+ irq_data.args[1] = hwirq - OMAP44XX_IRQ_GIC_START;
+ irq_data.args[2] = IRQ_TYPE_LEVEL_HIGH;
+
+ irq = irq_create_of_mapping(&irq_data);
+ if (WARN_ON(!irq))
+ irq = hwirq;
+
+ return irq;
+}
+
void __init omap_gic_of_init(void)
{
struct device_node *np;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908d..9025fff 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3534,9 +3534,15 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
mpu_irqs_cnt = _count_mpu_irqs(oh);
for (i = 0; i < mpu_irqs_cnt; i++) {
+ unsigned int irq;
+
+ if (oh->xlate_irq)
+ irq = oh->xlate_irq((oh->mpu_irqs + i)->irq);
+ else
+ irq = (oh->mpu_irqs + i)->irq;
(res + r)->name = (oh->mpu_irqs + i)->name;
- (res + r)->start = (oh->mpu_irqs + i)->irq;
- (res + r)->end = (oh->mpu_irqs + i)->irq;
+ (res + r)->start = irq;
+ (res + r)->end = irq;
(res + r)->flags = IORESOURCE_IRQ;
r++;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 35ca6ef..5b42faf 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -676,6 +676,7 @@ struct omap_hwmod {
spinlock_t _lock;
struct list_headnode;
struct omap_hwmod_ocp_if*_mpu_port;
+ unsigned int(*xlate_irq)(unsigned int);
u16 flags;
u8 mpu_rt_idx;
u8 response_lat;
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c314b3c..f5e68a7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -479,6 +479,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
.class =
Re: [PATCH 1/1] gpio: omap: Fix bad device access with setup_irq()
On Fri, Jan 16, 2015 at 04:19:41PM -0800, santosh shilimkar wrote: > On 1/16/2015 2:50 PM, Tony Lindgren wrote: > >Similar to omap_gpio_irq_type() let's make sure that the GPIO > >is usable as an interrupt if the platform init code did not > >call gpio_request(). Otherwise we can get invalid device access > >after setup_irq(): > > > I let Linus W comment on it but IIRC we chewed this issue last > time and the conclusion was the gpio_request() must have to be called > directly or indirectly in case of irq line. That's really not the issue here. The issue is that it's possible to claim the interrupt, and then the driver goes wrong - not only does it attempt in that case to access hardware which is runtime suspended, if the interrupt is subsequently freed, it will then do a pm_runtime_put(). The interrupt code is wrong there, plain and simple. -- 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Wednesday 26 November 2014 18:54:12 Tony Lindgren wrote: > * Pali Rohár [141125 13:33]: > > On Tuesday 25 November 2014 22:08:17 Pali Rohár wrote: > > > On Sunday 08 December 2013 00:22:06 Tony Lindgren wrote: > > > > * Sebastian Reichel [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 documentation (I only have > > > > > > > access to the public one) and crypto related > > > > > > > stuff is not documented for the > > > > > > > L3_PM_READ_PERMISSION register. There are a > > > > > > > couple of reserved bits, which may be used for > > > > > > > this, though. > > > > > > > > > > > > > > I also CC'd Joel Fernandes, since he worked on the > > > > > > > driver before and may have access to the > > > > > > > documentation. > > > > > > > > > > > > Looks like at least the 36xx public version > > > > > > referenced here has them: > > > > > > > > > > > > http://www.spinics.net/lists/linux-omap/msg21857.htm > > > > > > l > > > > > > > > > > > > I'd assume the registers are the same for 34xx since > > > > > > we don't have them defined separately in the > > > > > > kernel. > > > > > > > > > > I can't find it in the omap36xx documentation either. > > > > > Maybe I search at the wrong position. I tried to find > > > > > something crypto related in > > > > > > > > > > Table 9-89. L3_PM_READ_PERMISSION_i > > > > > > > > Hmm maybe it's done based on the address in > > > > L3_PM_ADDR_MATCH_k? > > > > > > > > I guess the thing to do would be to compare the register > > > > output between the two different firmware versions. > > > > > > > > Regards, > > > > > > > > Tony > > > > > > Tony, if you can tell me how to read those registers I can > > > provide output from both bootloaders (one that enable aes > > > support in L3 firewall and one which not). > > > > > > Also I can test other patches or provide other logs if you > > > need something more... > > > > CCing Nishanth Menon > > Maybe just try dumping out the L3_PM_ADDR_MATCH_* registers > during the boot? > > > Problem is that when L3 firewall is not configured by signed > > bootloader then loading omap aes driver cause kernel crash. > > We need some code which can check if omap aes is enabled or > > not at runtime in kernel... > > > > More details with full email tread conversation is there: > > http://thread.gmane.org/gmane.linux.ports.arm.omap/108397/ > > AFAIK we can't change the configuration, but it should be > readable somewhere. Sorry don't know which registers would > show the configuration other than the L3_PM_ADDR_MATCH_* > registers. > > Regards, > > Tony Hello, after playing with aes and non-aes version of bootloaders I found out that code which configure L3 firewall must be in signed X-Loader part. So probably we cannot change configuration at runtime... Tony, any idea how to dump L3_PM_ADDR_MATCH_* registers from userspace or from kernel? Now I have configured one N900 with original Nokia X-Loader (where loading omap aes driver cause kernel crash) and one N900 with aes X-Loader (where loading omap aes driver is working). -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
