Re: [PATCH v6 5/7] net: cpsw: Add am33xx MACID readout
On Mon, Sep 08, 2014 at 09:51:17AM -0700, Tony Lindgren wrote:
* Markus Pargmann m...@pengutronix.de [140907 10:20]:
This patch adds a function to get the MACIDs from the am33xx SoC
control module registers which hold unique vendor MACIDs. This is only
used if of_get_mac_address() fails to get a valid mac address.
...
@@ -1928,8 +1960,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data
*data,
PHY_ID_FMT, mdio-name, phyid);
mac_addr = of_get_mac_address(slave_node);
- if (mac_addr)
+ if (mac_addr) {
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
+ } else {
+ if (of_machine_is_compatible(ti,am33xx)) {
+ ret = cpsw_am33xx_cm_get_macid(pdev-dev, i,
+ slave_data-mac_addr);
+ if (ret)
+ return ret;
+ }
+ }
slave_data-phy_if = of_get_phy_mode(slave_node);
if (slave_data-phy_if 0) {
Thanks for updating this, this looks more future proof for adding
the dra7 related patch.
For the long run, it probably makes sense to add SoC specific
compatible values such as ti,cpsw-am3350 and so on. Then the
mac address functions can be initialized based on the of_device_id
entry for .data. The wiring is cleary SoC specific here.
The hardware doesn't differ across the SoCs, so I thought it may be
better to keep one compatible and parse the machine compatible for the
MACID location. But different compatible values are also ok.
So for the purpose of this series, I'm fine with this series,
please feel free to add for this patch:
Acked-by: Tony Lindgren t...@atomide.com
Thanks.
Best regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On 09/08/2014 07:55 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140908 10:41]: * Sebastian Andrzej Siewior bige...@linutronix.de [140905 12:03]: This is my complete queue fo the omap serial driver based on the 8250 core code. I played with it on beagle bone, am335x-evm and dra7xx including DMA. The runtime-pm pieces look now bug-compatible with the omap-serial driver. Besides the runtime-om improvement I also fixed a few corner cases for the TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the problem has been in 8250-dma via patch #13. The whole queue is available at git://git.breakpoint.cc/bigeasy/linux.git uart_v8 Gave the above branch a quick try, but it again does not idle for my omap3 test cases. It seems that now the cm_idlest1_core sdma bit is blocking deeper idle states. Is that the correct branch to use? Never mind. User error. I forgot to apply my own patch for force idling the UARTs for the omap hwmod. And the sdma bit clears if I do sleep 5 before attempting to read the sysfs entry.. Okay. There is also this uart_v8_hacks branch where I splitted out the hacks I had like the pstore one or the force idle for instance. Regards, Tony Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/8] ARM: dts: am33xx: Add external clock provider
On 09/09/2014 02:30 AM, Tony Lindgren wrote:
* Jyri Sarha jsa...@ti.com [140818 14:49]:
Add external clock provider for am33xx devices.
Please send all the .dts and defconfig changes separately
so I can pick them up and we don't get pointless merge
conflicts.
Moreover, this patch is obsolete now, given I have posted this:
http://www.spinics.net/lists/arm-kernel/msg355992.html
There will be v2 of my patch coming in though this week, but the
functionality will be the same.
-Tero
Regards,
TOny
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161..d2cc397 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -92,6 +92,16 @@
pinctrl-single,function-mask = 0x7f;
};
+ ext_clocks {
+ compatible = ti,external-clocks;
+
+ ext_clocks: clocks {
+ };
+
+ ext_clockdomains: clockdomains {
+ };
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex. Since
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/13] ARM: dts: DRA7: Add DCAN nodes
Hi,
On 09/08/2014 07:40 PM, Sergei Shtylyov wrote:
Hello.
On 9/8/2014 6:10 PM, Roger Quadros wrote:
The SoC supports 2 DCAN nodes. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..4ce1a4f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
[...]
@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+dcan1: d_can@481cc000 {
The ePAPR standard has something to say here:
The name of a node should be somewhat generic, reflecting the function of the
device and not its precise programming model. If appropriate, the name should
be one of the following choices:
• can
Right. I'll fix it up.
+compatible = bosch,d_can;
+ti,hwmods = dcan1;
+reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within syscon */
+raminit-syscon = dra7_ctrl_core;
+raminit-start-bit = 3;
+raminit-done-bit = 1;
+raminit-pulse;
Hm, aren't the above 4 properties vendor specific? If so, they should
start with a vendor prefix and comma.
At least for now I don't know about any other platform other than TI using a
RAMINIT register outside the
CAN register space. However the mechanism is generic enough and not limited to
TI platforms.
I don't mind vendor prefix or not, but would like to hear the opinion of the
CAN maintainers as to what they would prefer.
+interrupts = GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH;
+clocks = dcan1_sys_clk_mux;
+status = disabled;
+};
cheers,
-roger
--
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 3/3] nand: omap2: Replace pr_err with dev_err
On 09/08/2014 05:35 PM, Ezequiel Garcia wrote:
On 08 Sep 02:57 PM, Roger Quadros wrote:
Hi Ezequiel,
On 09/08/2014 02:27 PM, Ezequiel Garcia wrote:
Usage of pr_err is frowned upon, so replace it with dev_err.
Aditionally, the message on nand_bch_init() error is redundant,
since proper error is showed if the function fails.
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
drivers/mtd/nand/omap2.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f97a4ff..eb5e898 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1375,7 +1375,7 @@ static int omap_elm_correct_data(struct mtd_info
*mtd, u_char *data,
erased_ecc_vec = bch16_vector;
break;
default:
- pr_err(invalid driver configuration\n);
+ dev_err(info-pdev-dev, invalid driver configuration\n);
return -EINVAL;
}
@@ -1446,7 +1446,8 @@ static int omap_elm_correct_data(struct mtd_info
*mtd, u_char *data,
err = 0;
for (i = 0; i eccsteps; i++) {
if (err_vec[i].error_uncorrectable) {
- pr_err(nand: uncorrectable bit-flips found\n);
+ dev_err(info-pdev-dev,
+ uncorrectable bit-flips found\n);
err = -EBADMSG;
} else if (err_vec[i].error_reported) {
for (j = 0; j err_vec[i].error_count; j++) {
@@ -1483,8 +1484,9 @@ static int omap_elm_correct_data(struct mtd_info
*mtd, u_char *data,
1 bit_pos;
}
} else {
- pr_err(invalid bit-flip @ %d:%d\n,
-byte_pos, bit_pos);
+ dev_err(info-pdev-dev,
+ invalid bit-flip @ %d:%d\n,
+ byte_pos, bit_pos);
err = -EBADMSG;
}
}
@@ -1598,13 +1600,13 @@ static bool is_elm_present(struct omap_nand_info
*info,
/* check whether elm-id is passed via DT */
if (!elm_node) {
- pr_err(nand: error: ELM DT node not found\n);
+ dev_err(info-pdev-dev, ELM devicetree node not found\n);
return false;
}
pdev = of_find_device_by_node(elm_node);
/* check whether ELM device is registered */
if (!pdev) {
- pr_err(nand: error: ELM device not found\n);
+ dev_err(info-pdev-dev, ELM device not found\n);
return false;
}
/* ELM module available, now configure it */
@@ -1734,14 +1736,14 @@ static int omap_nand_probe(struct platform_device
*pdev)
/* scan NAND device connected to chip controller */
nand_chip-options |= pdata-devsize NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
- pr_err(nand device scan failed, may be bus-width mismatch\n);
+ dev_err(info-pdev-dev, scan failed, may be bus-width
mismatch\n);
err = -ENXIO;
goto return_error;
}
/* check for small page devices */
if ((mtd-oobsize 64) (pdata-ecc_opt != OMAP_ECC_HAM1_CODE_HW)) {
- pr_err(small page devices are not supported\n);
+ dev_err(info-pdev-dev, small page devices are not
supported\n);
err = -EINVAL;
goto return_error;
}
@@ -1959,7 +1961,6 @@ static int omap_nand_probe(struct platform_device
*pdev)
nand_chip-ecc.bytes,
ecclayout);
if (!nand_chip-ecc.priv) {
- pr_err(nand: error: unable to use s/w BCH library\n);
Where would the error be printed in this case?
Well, nand_bch_init() has a lot of messages for the errors, but I just noticed
some cases where there's no message printed. Would you prefer to leave these
untouched?
Yes, let's leave these messages here to tackle the cases where error messages
aren't printed
in nand_bch_init().
I also noticed a similar message in the OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
case.
And it seems to be missing a goto return_error there.
Argh, right. I'll have to resend this one.
cheers,
-roger
--
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 05/13] ARM: dts: DRA7: Add DCAN nodes
On 09/09/2014 10:30 AM, Roger Quadros wrote: +compatible = bosch,d_can; +ti,hwmods = dcan1; +reg = 0x4ae3c000 0x2000, + 0x558 0x4; /* index to RAMINIT reg within syscon */ +raminit-syscon = dra7_ctrl_core; +raminit-start-bit = 3; +raminit-done-bit = 1; +raminit-pulse; Hm, aren't the above 4 properties vendor specific? If so, they should start with a vendor prefix and comma. At least for now I don't know about any other platform other than TI using a RAMINIT register outside the CAN register space. However the mechanism is generic enough and not limited to TI platforms. I don't mind vendor prefix or not, but would like to hear the opinion of the CAN maintainers as to what they would prefer. I don't know of any c_can/d_can implementation outside of TI that implements the raminit outside of the register space. So a ti, prefix seems appropriate. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 1/3] nand: omap2: Add support for flash-based bad block table
Ezequiel,
On 09/08/2014 02:27 PM, Ezequiel Garcia wrote:
This commit adds a new platform-data boolean property that enables use
of a flash-based bad block table. This can also be enabled by setting
the 'nand-on-flash-bbt' devicetree property.
I'm not much aware of how on-flash-BBT works internally, but will it break
things if
we keep on-flash-BBT enabled as the default option and add a DT property only
to
explicitly disable the on-flash-BBT?
If the flash BBT is not enabled, the driver falls back to use OOB
bad block markers only, as before. If the flash BBT is enabled the
kernel will keep track of bad blocks using a BBT, in addition to
the OOB markers.
As explained by Brian Norris the reasons for using a BBT are:
The primary reason would be that NAND datasheets specify it these days.
A better argument is that nobody guarantees that you can write a
bad block marker to a worn out block; you may just get program failures.
This has been acknowledged by several developers over the last several
years.
Additionally, you get a boot-time performance improvement if you only
have to read a few pages, instead of a page or two from every block on
the flash.
cheers,
-roger
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
arch/arm/mach-omap2/gpmc.c | 2 ++
drivers/mtd/nand/omap2.c | 6 +-
include/linux/platform_data/mtd-nand-omap2.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2f97228..b55a225 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1440,6 +1440,8 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
break;
}
+ gpmc_nand_data-flash_bbt = of_get_nand_on_flash_bbt(child);
+
val = of_get_nand_bus_width(child);
if (val == 16)
gpmc_nand_data-devsize = NAND_BUSWIDTH_16;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5967b38..e1a9b31 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1663,7 +1663,6 @@ static int omap_nand_probe(struct platform_device *pdev)
mtd-owner = THIS_MODULE;
nand_chip = info-nand;
nand_chip-ecc.priv = NULL;
- nand_chip-options |= NAND_SKIP_BBTSCAN;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
nand_chip-IO_ADDR_R = devm_ioremap_resource(pdev-dev, res);
@@ -1692,6 +1691,11 @@ static int omap_nand_probe(struct platform_device
*pdev)
nand_chip-chip_delay = 50;
}
+ if (pdata-flash_bbt)
+ nand_chip-bbt_options |= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
+ else
+ nand_chip-options |= NAND_SKIP_BBTSCAN;
+
/* scan NAND device connected to chip controller */
nand_chip-options |= pdata-devsize NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 16ec262..090bbab 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -71,6 +71,7 @@ struct omap_nand_platform_data {
struct mtd_partition*parts;
int nr_parts;
booldev_ready;
+ boolflash_bbt;
enum nand_ioxfer_type;
int devsize;
enum omap_ecc ecc_opt;
--
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 05/13] ARM: dts: DRA7: Add DCAN nodes
Hi Marc, On 09/09/2014 11:34 AM, Marc Kleine-Budde wrote: On 09/09/2014 10:30 AM, Roger Quadros wrote: +compatible = bosch,d_can; +ti,hwmods = dcan1; +reg = 0x4ae3c000 0x2000, + 0x558 0x4; /* index to RAMINIT reg within syscon */ +raminit-syscon = dra7_ctrl_core; +raminit-start-bit = 3; +raminit-done-bit = 1; +raminit-pulse; Hm, aren't the above 4 properties vendor specific? If so, they should start with a vendor prefix and comma. At least for now I don't know about any other platform other than TI using a RAMINIT register outside the CAN register space. However the mechanism is generic enough and not limited to TI platforms. I don't mind vendor prefix or not, but would like to hear the opinion of the CAN maintainers as to what they would prefer. I don't know of any c_can/d_can implementation outside of TI that implements the raminit outside of the register space. So a ti, prefix seems appropriate. Fine, I'll re-spin this with the ti, prefix. Thanks. cheers, -roger -- 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: [resend PATCH 1/3] pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC
On Tuesday 09 September 2014 01:02 AM, Nishanth Menon wrote: A) There is no OFF mode on DRA7. in sleep state use mode 15 (gated). B) when using this for wakeup - use pinctrl wakeup handling to do the wakeup. Will drop this patch and use mode 15 in sleep mode and submit v2 patch series Regards Mugunthan V N -- 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 v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman khil...@linaro.org wrote: To me, it's not terribly clear how you made the split between this PM core code an the remoteproc code. In the changelog for the remoteproc patch, it states it's to load the firmware for and boot the wkup_m3. But, while parts of the IPC are here in pm33xx.c, parts of the IPC are also inside the remoteproc driver, so I'm quite curious if that's OK with the remoteproc maintainers. Either way, please make it clearer how and why you made the split, and please isolate the wkup_m3 IPC/protocol from this code. Think of people wanting to rework/extend the wkup_m3 firmware. They shouldn't be messing around in here, but rather inside a driver specificaly for the wkup_m3. I haven't looked at the code very thoroughly yet, but generally a remoteproc driver should only implement the three start/stop/kick rproc_ops, and then register them via the remoteproc framework. Exposing additional API directly from that driver isn't something we immediately want to accept. If relevant, we would generally prefer to extend remoteproc instead, so other platform-specific drivers could utilize that functionality as well. Or rpmsg - if we're missing some IPC functionality. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] kbuild: remove unnecessary variable initializaions
Clearing obj-y, obj-m, obj-n, obj- in each Makefile is a useless habit. They are non-exported variables; therefore they are always empty whenever descending into each subdirectory. (Moreorver, obj-y and obj-m are also set to empty at the beginning of scripts/Makefile.build) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- arch/arm/mach-at91/Makefile | 3 --- arch/arm/mach-ebsa110/Makefile| 3 --- arch/arm/mach-ep93xx/Makefile | 3 --- arch/arm/mach-exynos/Makefile | 5 - arch/arm/mach-footbridge/Makefile | 3 --- arch/arm/mach-iop13xx/Makefile| 5 - arch/arm/mach-iop32x/Makefile | 3 --- arch/arm/mach-iop33x/Makefile | 3 --- arch/arm/mach-ks8695/Makefile | 3 --- arch/arm/mach-rpc/Makefile| 4 arch/arm/mach-s3c24xx/Makefile| 5 - arch/arm/mach-s3c64xx/Makefile| 5 - arch/arm/mach-s5pv210/Makefile| 5 - arch/arm/mach-sa1100/Makefile | 3 --- arch/arm/mach-u300/Makefile | 3 --- arch/arm/plat-iop/Makefile| 6 -- arch/arm/plat-omap/Makefile | 3 --- arch/arm/plat-samsung/Makefile| 4 18 files changed, 69 deletions(-) diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile index 78e9cec..75033839 100644 --- a/arch/arm/mach-at91/Makefile +++ b/arch/arm/mach-at91/Makefile @@ -3,9 +3,6 @@ # obj-y := irq.o gpio.o setup.o sysirq_mask.o -obj-m := -obj-n := -obj- := obj-$(CONFIG_OLD_CLK_AT91) += clock.o obj-$(CONFIG_AT91_SAM9_ALT_RESET) += at91sam9_alt_reset.o diff --git a/arch/arm/mach-ebsa110/Makefile b/arch/arm/mach-ebsa110/Makefile index 935e4af..a7d68c1 100644 --- a/arch/arm/mach-ebsa110/Makefile +++ b/arch/arm/mach-ebsa110/Makefile @@ -5,6 +5,3 @@ # Object file lists. obj-y := core.o io.o leds.o -obj-m := -obj-n := -obj- := diff --git a/arch/arm/mach-ep93xx/Makefile b/arch/arm/mach-ep93xx/Makefile index 0dc51f9..78d427b 100644 --- a/arch/arm/mach-ep93xx/Makefile +++ b/arch/arm/mach-ep93xx/Makefile @@ -2,9 +2,6 @@ # Makefile for the linux kernel. # obj-y := core.o clock.o -obj-m := -obj-n := -obj- := obj-$(CONFIG_EP93XX_DMA) += dma.o diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 788f26d..27ae614 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -7,11 +7,6 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include -obj-y := -obj-m := -obj-n := -obj- := - # Core obj-$(CONFIG_ARCH_EXYNOS) += exynos.o pmu.o exynos-smc.o firmware.o diff --git a/arch/arm/mach-footbridge/Makefile b/arch/arm/mach-footbridge/Makefile index c3faa3b..e83d5c8 100644 --- a/arch/arm/mach-footbridge/Makefile +++ b/arch/arm/mach-footbridge/Makefile @@ -5,9 +5,6 @@ # Object file lists. obj-y := common.o dma.o isa-irq.o -obj-m := -obj-n := -obj- := pci-y += dc21285.o pci-$(CONFIG_ARCH_CATS) += cats-pci.o diff --git a/arch/arm/mach-iop13xx/Makefile b/arch/arm/mach-iop13xx/Makefile index cad015f..a3d9260 100644 --- a/arch/arm/mach-iop13xx/Makefile +++ b/arch/arm/mach-iop13xx/Makefile @@ -1,8 +1,3 @@ -obj-y := -obj-m := -obj-n := -obj- := - obj-$(CONFIG_ARCH_IOP13XX) += setup.o obj-$(CONFIG_ARCH_IOP13XX) += irq.o obj-$(CONFIG_ARCH_IOP13XX) += pci.o diff --git a/arch/arm/mach-iop32x/Makefile b/arch/arm/mach-iop32x/Makefile index cfdf8a1..2d4010a 100644 --- a/arch/arm/mach-iop32x/Makefile +++ b/arch/arm/mach-iop32x/Makefile @@ -3,9 +3,6 @@ # obj-y := irq.o -obj-m := -obj-n := -obj- := obj-$(CONFIG_MACH_GLANTANK) += glantank.o obj-$(CONFIG_ARCH_IQ80321) += iq80321.o diff --git a/arch/arm/mach-iop33x/Makefile b/arch/arm/mach-iop33x/Makefile index 90081d8..e95db30 100644 --- a/arch/arm/mach-iop33x/Makefile +++ b/arch/arm/mach-iop33x/Makefile @@ -3,9 +3,6 @@ # obj-y := irq.o uart.o -obj-m := -obj-n := -obj- := obj-$(CONFIG_ARCH_IQ80331) += iq80331.o obj-$(CONFIG_MACH_IQ80332) += iq80332.o diff --git a/arch/arm/mach-ks8695/Makefile b/arch/arm/mach-ks8695/Makefile index e370caf..8ecb797 100644 --- a/arch/arm/mach-ks8695/Makefile +++ b/arch/arm/mach-ks8695/Makefile @@ -4,9 +4,6 @@ # obj-y := cpu.o irq.o time.o devices.o -obj-m := -obj-n := -obj- := # PCI support is optional obj-$(CONFIG_PCI) += pci.o diff --git a/arch/arm/mach-rpc/Makefile
[PATCH 0/3] kbuild: Clean up makefiles and then drop obj-n an obj-n
Masahiro Yamada (3): kbuild: remove unnecessary obj- := dummy.o trick kbuild: remove unnecessary variable initializaions kbuild: remove obj-n and lib-n handling arch/arm/mach-at91/Makefile | 3 --- arch/arm/mach-ebsa110/Makefile| 3 --- arch/arm/mach-ep93xx/Makefile | 3 --- arch/arm/mach-exynos/Makefile | 5 - arch/arm/mach-footbridge/Makefile | 3 --- arch/arm/mach-iop13xx/Makefile| 5 - arch/arm/mach-iop32x/Makefile | 3 --- arch/arm/mach-iop33x/Makefile | 3 --- arch/arm/mach-ks8695/Makefile | 3 --- arch/arm/mach-rpc/Makefile| 4 arch/arm/mach-s3c24xx/Makefile| 5 - arch/arm/mach-s3c64xx/Makefile| 5 - arch/arm/mach-s5pv210/Makefile| 5 - arch/arm/mach-sa1100/Makefile | 3 --- arch/arm/mach-u300/Makefile | 3 --- arch/arm/plat-iop/Makefile| 6 -- arch/arm/plat-omap/Makefile | 3 --- arch/arm/plat-samsung/Makefile| 5 - drivers/clk/shmobile/Makefile | 2 -- drivers/net/wimax/Makefile| 4 firmware/Makefile | 2 +- scripts/Makefile.build| 4 ++-- scripts/Makefile.clean| 4 +--- scripts/Makefile.fwinst | 2 +- 24 files changed, 5 insertions(+), 83 deletions(-) -- 1.9.1 -- 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: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
On Tuesday 09 September 2014 01:04 AM, Nishanth Menon wrote: On 00:49-20140909, Mugunthan V N wrote: Adding device tree entry for CPSW to make it work in Dual EMAC mode. These patches were tested with DRA7 hwmod patches on top of linux-next. The patches were already reviewed [1] and has been waiting for cross bar and hwmod to be pulled in. Now since all dependent patches has already pulled in, so reposting the patches again. Patches are tested on linux-next, the boot logs on DRA7xx EVM [2] [1] https://lkml.org/lkml/2014/5/13/89 [2] http://slexy.org/view/s2YqO0Wj9b Sorry this is now blocked inside TI. could you explain the testing done for sleep state? did you attempt sleep mode before testing this? I have not tested sleep mode, just tested boot and ping test. Regards Mugunthan V N -- 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 2/3] kbuild: remove unnecessary variable initializaions
On 09/09/2014 12:26, Masahiro Yamada : Clearing obj-y, obj-m, obj-n, obj- in each Makefile is a useless habit. They are non-exported variables; therefore they are always empty whenever descending into each subdirectory. (Moreorver, obj-y and obj-m are also set to empty at the beginning of scripts/Makefile.build) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- arch/arm/mach-at91/Makefile | 3 --- arch/arm/mach-ebsa110/Makefile| 3 --- arch/arm/mach-ep93xx/Makefile | 3 --- arch/arm/mach-exynos/Makefile | 5 - arch/arm/mach-footbridge/Makefile | 3 --- arch/arm/mach-iop13xx/Makefile| 5 - arch/arm/mach-iop32x/Makefile | 3 --- arch/arm/mach-iop33x/Makefile | 3 --- arch/arm/mach-ks8695/Makefile | 3 --- arch/arm/mach-rpc/Makefile| 4 arch/arm/mach-s3c24xx/Makefile| 5 - arch/arm/mach-s3c64xx/Makefile| 5 - arch/arm/mach-s5pv210/Makefile| 5 - arch/arm/mach-sa1100/Makefile | 3 --- arch/arm/mach-u300/Makefile | 3 --- arch/arm/plat-iop/Makefile| 6 -- arch/arm/plat-omap/Makefile | 3 --- arch/arm/plat-samsung/Makefile| 4 18 files changed, 69 deletions(-) diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile index 78e9cec..75033839 100644 --- a/arch/arm/mach-at91/Makefile +++ b/arch/arm/mach-at91/Makefile @@ -3,9 +3,6 @@ # obj-y:= irq.o gpio.o setup.o sysirq_mask.o -obj-m:= -obj-n:= -obj- := I agree: Acked-by: Nicolas Ferre nicolas.fe...@atmel.com But I have patches that will mess with these changes already queued for 3.18. You may have to signal these conflicts when carrying the patch upstream. Thanks, best regards, obj-$(CONFIG_OLD_CLK_AT91) += clock.o obj-$(CONFIG_AT91_SAM9_ALT_RESET) += at91sam9_alt_reset.o diff --git a/arch/arm/mach-ebsa110/Makefile b/arch/arm/mach-ebsa110/Makefile index 935e4af..a7d68c1 100644 --- a/arch/arm/mach-ebsa110/Makefile +++ b/arch/arm/mach-ebsa110/Makefile @@ -5,6 +5,3 @@ # Object file lists. obj-y:= core.o io.o leds.o -obj-m:= -obj-n:= -obj- := diff --git a/arch/arm/mach-ep93xx/Makefile b/arch/arm/mach-ep93xx/Makefile index 0dc51f9..78d427b 100644 --- a/arch/arm/mach-ep93xx/Makefile +++ b/arch/arm/mach-ep93xx/Makefile @@ -2,9 +2,6 @@ # Makefile for the linux kernel. # obj-y:= core.o clock.o -obj-m:= -obj-n:= -obj- := obj-$(CONFIG_EP93XX_DMA) += dma.o diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 788f26d..27ae614 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -7,11 +7,6 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include -obj-y:= -obj-m:= -obj-n:= -obj- := - # Core obj-$(CONFIG_ARCH_EXYNOS)+= exynos.o pmu.o exynos-smc.o firmware.o diff --git a/arch/arm/mach-footbridge/Makefile b/arch/arm/mach-footbridge/Makefile index c3faa3b..e83d5c8 100644 --- a/arch/arm/mach-footbridge/Makefile +++ b/arch/arm/mach-footbridge/Makefile @@ -5,9 +5,6 @@ # Object file lists. obj-y:= common.o dma.o isa-irq.o -obj-m:= -obj-n:= -obj- := pci-y+= dc21285.o pci-$(CONFIG_ARCH_CATS) += cats-pci.o diff --git a/arch/arm/mach-iop13xx/Makefile b/arch/arm/mach-iop13xx/Makefile index cad015f..a3d9260 100644 --- a/arch/arm/mach-iop13xx/Makefile +++ b/arch/arm/mach-iop13xx/Makefile @@ -1,8 +1,3 @@ -obj-y:= -obj-m:= -obj-n:= -obj- := - obj-$(CONFIG_ARCH_IOP13XX) += setup.o obj-$(CONFIG_ARCH_IOP13XX) += irq.o obj-$(CONFIG_ARCH_IOP13XX) += pci.o diff --git a/arch/arm/mach-iop32x/Makefile b/arch/arm/mach-iop32x/Makefile index cfdf8a1..2d4010a 100644 --- a/arch/arm/mach-iop32x/Makefile +++ b/arch/arm/mach-iop32x/Makefile @@ -3,9 +3,6 @@ # obj-y:= irq.o -obj-m:= -obj-n:= -obj- := obj-$(CONFIG_MACH_GLANTANK) += glantank.o obj-$(CONFIG_ARCH_IQ80321) += iq80321.o diff --git a/arch/arm/mach-iop33x/Makefile b/arch/arm/mach-iop33x/Makefile index 90081d8..e95db30 100644 --- a/arch/arm/mach-iop33x/Makefile +++ b/arch/arm/mach-iop33x/Makefile @@ -3,9 +3,6 @@ # obj-y:= irq.o uart.o -obj-m:= -obj-n:= -obj- :=
Re: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
On Tue, Sep 9, 2014 at 6:29 AM, Mugunthan V N mugunthan...@ti.com wrote: Sorry this is now blocked inside TI. could you explain the testing done for sleep state? did you attempt sleep mode before testing this? I have not tested sleep mode, just tested boot and ping test. I must NAK then for the reason that this is a patch that is just build tested and is not tested for the feature it claims to introduce. -- --- Regards, Nishanth Menon -- 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: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
On Tuesday 09 September 2014 05:45 PM, Nishanth Menon wrote: On Tue, Sep 9, 2014 at 6:29 AM, Mugunthan V N mugunthan...@ti.com wrote: Sorry this is now blocked inside TI. could you explain the testing done for sleep state? did you attempt sleep mode before testing this? I have not tested sleep mode, just tested boot and ping test. I must NAK then for the reason that this is a patch that is just build tested and is not tested for the feature it claims to introduce. Is suspend/resume supported in mainline, i was not able to test it. root@dra7xx-evm:~# echo mem /sys/power/state -sh: echo: write error: Invalid argument I was not able to use rtc wake also as the rtc device is not created. Regards Mugunthan V N -- 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: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree
On 09/09/2014 07:56 AM, Mugunthan V N wrote: On Tuesday 09 September 2014 05:45 PM, Nishanth Menon wrote: On Tue, Sep 9, 2014 at 6:29 AM, Mugunthan V N mugunthan...@ti.com wrote: Sorry this is now blocked inside TI. could you explain the testing done for sleep state? did you attempt sleep mode before testing this? I have not tested sleep mode, just tested boot and ping test. I must NAK then for the reason that this is a patch that is just build tested and is not tested for the feature it claims to introduce. Is suspend/resume supported in mainline, i was not able to test it. root@dra7xx-evm:~# echo mem /sys/power/state -sh: echo: write error: Invalid argument I was not able to use rtc wake also as the rtc device is not created. Right.. that is why I was curious how you posted a patch that supposedly supports sleep pin configurations in a kernel that does not support suspend-resume? Hopefully we will have it supported in 3.18 kernel[1] - still need out of tree wakeup timer patch[2] for testing though.. If you have at least tested on relevant branch which has the feature expected for 3.18, I might still be OK with the patch. [1]http://marc.info/?l=linux-kernelm=141019565513129w=2 and http://marc.info/?l=linux-kernelm=141019566913133w=2 [2] details in http://marc.info/?l=linux-kernelm=140871637106555w=2 -- Regards, Nishanth Menon -- 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 1/3] nand: omap2: Add support for flash-based bad block table
On 09 Sep 11:35 AM, Roger Quadros wrote: Ezequiel, On 09/08/2014 02:27 PM, Ezequiel Garcia wrote: This commit adds a new platform-data boolean property that enables use of a flash-based bad block table. This can also be enabled by setting the 'nand-on-flash-bbt' devicetree property. I'm not much aware of how on-flash-BBT works internally, but will it break things if we keep on-flash-BBT enabled as the default option and add a DT property only to explicitly disable the on-flash-BBT? No, that wouldn't work because the DT property already exists and it works to enable the flash BBT when it's present. Documentation/devicetree/bindings/mtd/nand.txt Of course, we can add a new no-nand-on-flash-bbt, but I really don't see the point. Users can just put the property in all the devicetree board files where it's needed. And moreover, I don't want to change the default behavior of the driver; it's better to allow to *add* a new feature, if such feature is desired. Otherwise, users with some data in a flash's last blocks would be wiped and replaced with the BBT. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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 1/3] nand: omap2: Add support for flash-based bad block table
On 09/09/2014 04:27 PM, Ezequiel Garcia wrote: On 09 Sep 11:35 AM, Roger Quadros wrote: Ezequiel, On 09/08/2014 02:27 PM, Ezequiel Garcia wrote: This commit adds a new platform-data boolean property that enables use of a flash-based bad block table. This can also be enabled by setting the 'nand-on-flash-bbt' devicetree property. I'm not much aware of how on-flash-BBT works internally, but will it break things if we keep on-flash-BBT enabled as the default option and add a DT property only to explicitly disable the on-flash-BBT? No, that wouldn't work because the DT property already exists and it works to enable the flash BBT when it's present. Documentation/devicetree/bindings/mtd/nand.txt Of course, we can add a new no-nand-on-flash-bbt, but I really don't see the point. Users can just put the property in all the devicetree board files where it's needed. And moreover, I don't want to change the default behavior of the driver; it's better to allow to *add* a new feature, if such feature is desired. Otherwise, users with some data in a flash's last blocks would be wiped and replaced with the BBT. OK. Let's stick with your patch then. cheers, -roger -- 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
[GIT PULL] ARM: dts: OMAP5 / DRA7: pinctrl updates
Hi Tony, Please pull this series was posted[1] and based on the previous pulls [2] [3], updating the dts to enable the relevant feature. NOTE: I have dropped patch #1 of the series based on [4]. These could go to your branch omap-for-v3.18/dt The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-dt-pinctrl-updates for you to fetch changes up to 66b0436977e2c62388d48836ff784f1fedb49c4f: ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable (2014-09-09 08:33:29 -0500) Nishanth Menon (5): ARM: dts: OMAP5: switch to compatible pinctrl ARM: dts: DRA7: switch to compatible pinctrl ARM: dts: AM437x: switch to compatible pinctrl ARM: dts: OMAP5 / DRA7: switch over to interrupts-extended property for UART ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable arch/arm/boot/dts/am4372.dtsi |4 +++- arch/arm/boot/dts/dra7-evm.dts |2 ++ arch/arm/boot/dts/dra7.dtsi| 24 +--- arch/arm/boot/dts/omap5.dtsi | 20 4 files changed, 30 insertions(+), 20 deletions(-) [1] http://marc.info/?l=linux-kernelm=140871681606779w=2 [2] http://marc.info/?l=linux-kernelm=141019565513129w=2 [3] http://marc.info/?l=linux-kernelm=141019566913133w=2 [4] http://marc.info/?l=linux-omapm=141022429924564w=2 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] net: can: Use syscon regmap for TI specific RAMINIT register
Hi, Some hardware (TI am43xx) has a buggy RAMINIT DONE mechanism and it might not always set the DONE bit. This will result in a lockup in c_can_hw_raminit_wait_ti(), so patch 1 adds a timeout mechanism there. There is a non compliancy within TI platforms with respect to the layout of the RAMINIT register. The patches 2 and 3 address this issue and make a flexible but standard way of defining the RAMINIT hardware register layout in the device tree. The RAMINIT register is accessed using the syscon regmap framework. Patches available at g...@github.com:rogerq/linux.git[for-v3.18/can] Changelog: v2: - added ti vendor prefix to TI specific raminit properties. - split DTS changes into a separate series cheers, -roger --- Roger Quadros (3): can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout net: can: c_can: Add syscon/regmap RAMINIT mechanism net: can: c_can: Add support for START pulse in RAMINIT sequence .../devicetree/bindings/net/can/c_can.txt | 10 ++ drivers/net/can/c_can/c_can.h | 12 +- drivers/net/can/c_can/c_can_platform.c | 123 - 3 files changed, 114 insertions(+), 31 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti().
They seem to have been swapped in the usage instances.
TI's RAMINIT DONE mechanism is buggy and may not always be
set after the START bit is set. So add a timeout mechanism to
c_can_hw_raminit_wait_ti().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can_platform.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 109cb44..b144e71 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -75,10 +75,18 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
u32 val)
{
+ int timeout = 0;
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val)
+ while ((readl(priv-raminit_ctrlreg) mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
+ dev_err(priv-dev-dev, %s: time out\n, __func__);
+ break;
+ }
+ }
}
static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
@@ -97,14 +105,14 @@ static void c_can_hw_raminit_ti(const struct c_can_priv
*priv, bool enable)
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl = ~CAN_RAMINIT_DONE_MASK(priv-instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
if (enable) {
/* Set start bit and wait for the done bit. */
ctrl |= CAN_RAMINIT_START_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
}
spin_unlock(raminit_lock);
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.
To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.
Provides a more generic mechanism to specify the RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/net/can/c_can.txt | 7 ++
drivers/net/can/c_can/c_can.h | 11 ++-
drivers/net/can/c_can/c_can_platform.c | 109 +++--
3 files changed, 95 insertions(+), 32 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 8f1ae81..e12d1a1 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -13,6 +13,13 @@ Optional properties:
- ti,hwmods: Must be d_cann or c_cann, n being the
instance number
+- ti,raminit-syscon: Handle to system control region that contains the
+ RAMINIT register. If specified, the second memory
resource
+ in the reg property must index into the RAMINIT
+ register within the syscon region
+- ti,raminit-start-bit : Bit posistion of START bit in the RAMINIT register
+- ti,raminit-done-bit : Bit position of DONE bit in the RAMINIT register
+
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 99ad1aa..bf68822 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,14 @@ enum c_can_dev_id {
BOSCH_D_CAN,
};
+/* Out of band RAMINIT register access via syscon regmap */
+struct c_can_raminit {
+ struct regmap *syscon; /* for raminit ctrl. reg. access */
+ unsigned int reg; /* register index within syscon */
+ u8 start_bit; /* START bit position in raminit reg. */
+ u8 done_bit;/* DONE bit position in raminit reg. */
+};
+
/* c_can private data structure */
struct c_can_priv {
struct can_priv can;/* must be the first member */
@@ -186,8 +194,7 @@ struct c_can_priv {
const u16 *regs;
void *priv; /* for board-specific data */
enum c_can_dev_id type;
- u32 __iomem *raminit_ctrlreg;
- int instance;
+ struct c_can_raminit raminit_sys; /* RAMINIT via syscon regmap */
void (*raminit) (const struct c_can_priv *priv, bool enable);
u32 comm_rcv_high;
u32 rxmasked;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index b144e71..fb0c35b 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,14 +32,13 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include linux/can/dev.h
#include c_can.h
-#define CAN_RAMINIT_START_MASK(i) (0x001 (i))
-#define CAN_RAMINIT_DONE_MASK(i) (0x100 (i))
-#define CAN_RAMINIT_ALL_MASK(i)(0x101 (i))
#define DCAN_RAM_INIT_BIT (1 3)
static DEFINE_SPINLOCK(raminit_lock);
/*
@@ -72,48 +71,59 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
}
-static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
- u32 val)
+static void c_can_hw_raminit_wait_syscon(const struct c_can_priv *priv,
+u32 mask, u32 val)
{
int timeout = 0;
+ const struct c_can_raminit *raminit = priv-raminit_sys;
+ u32 ctrl;
+
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val) {
+ do {
udelay(1);
timeout++;
+ regmap_read(raminit-syscon, raminit-reg, ctrl);
if (timeout == 1000) {
dev_err(priv-dev-dev, %s: time out\n, __func__);
break;
}
- }
+ } while ((ctrl mask) != val);
}
-static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
+static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable)
{
- u32 mask = CAN_RAMINIT_ALL_MASK(priv-instance);
+ u32 mask;
u32 ctrl;
+ const struct c_can_raminit *raminit = priv-raminit_sys;
spin_lock(raminit_lock);
- ctrl = readl(priv-raminit_ctrlreg);
+ mask = 1
[PATCH v2 3/3] net: can: c_can: Add support for START pulse in RAMINIT sequence
Some SoCs e.g. (TI DRA7xx) need a START pulse to start the
RAMINIT sequence i.e. START bit must be set and cleared before
checking for the DONE bit status. Add a new DT property raminit-pulse
to specify if this mechanism must be used for RAMINIT.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/net/can/c_can.txt | 3 +++
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/c_can/c_can_platform.c | 8
3 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index e12d1a1..705411f 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -19,6 +19,9 @@ Optional properties:
register within the syscon region
- ti,raminit-start-bit : Bit posistion of START bit in the RAMINIT register
- ti,raminit-done-bit : Bit position of DONE bit in the RAMINIT register
+- ti,raminit-pulse : Property must exist if START pulse is needed for
RAMINIT
+ sequence i.e. START bit will be set and cleared before
+ checking for DONE bit.
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index bf68822..85b5ad0 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -175,6 +175,7 @@ struct c_can_raminit {
unsigned int reg; /* register index within syscon */
u8 start_bit; /* START bit position in raminit reg. */
u8 done_bit;/* DONE bit position in raminit reg. */
+ bool needs_pulse; /* If set, sets and clears START bit (pulse) */
};
/* c_can private data structure */
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index fb0c35b..5ae9eb3 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -120,6 +120,12 @@ static void c_can_hw_raminit_syscon(const struct
c_can_priv *priv, bool enable)
ctrl |= 1 raminit-start_bit;
regmap_write(raminit-syscon, raminit-reg, ctrl);
+ /* clear START bit if start pulse is needed */
+ if (raminit-needs_pulse) {
+ ctrl = ~(1 raminit-start_bit);
+ regmap_write(raminit-syscon, raminit-reg, ctrl);
+ }
+
ctrl |= 1 raminit-done_bit;
c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
}
@@ -340,6 +346,8 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv-raminit_sys.done_bit = val;
+ priv-raminit_sys.needs_pulse = of_property_read_bool(np,
+
ti,raminit-pulse);
priv-raminit = c_can_hw_raminit_syscon;
break;
default:
--
1.8.3.2
--
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 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 09:31 AM, Roger Quadros wrote:
Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti().
They seem to have been swapped in the usage instances.
TI's RAMINIT DONE mechanism is buggy and may not always be
set after the START bit is set. So add a timeout mechanism to
c_can_hw_raminit_wait_ti().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can_platform.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 109cb44..b144e71 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -75,10 +75,18 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
u32 val)
{
+ int timeout = 0;
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val)
+ while ((readl(priv-raminit_ctrlreg) mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
How did we come up with this number?
+ dev_err(priv-dev-dev, %s: time out\n, __func__);
+ break;
lets say we did timeout..
see below:
+ }
+ }
}
static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
@@ -97,14 +105,14 @@ static void c_can_hw_raminit_ti(const struct c_can_priv
*priv, bool enable)
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl = ~CAN_RAMINIT_DONE_MASK(priv-instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
if (enable) {
/* Set start bit and wait for the done bit. */
ctrl |= CAN_RAMINIT_START_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
- c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+ c_can_hw_raminit_wait_ti(priv, mask, ctrl);
is it possible for us to continue? does it make sense for us to change
that void to a int and handle error cascading?
}
spin_unlock(raminit_lock);
}
--
Regards,
Nishanth Menon
--
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 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 04:31 PM, Roger Quadros wrote: Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti(). They seem to have been swapped in the usage instances. Can you split this fix into a seperate patch, please. TI's RAMINIT DONE mechanism is buggy and may not always be set after the START bit is set. So add a timeout mechanism to c_can_hw_raminit_wait_ti(). What should happen if the timeout occurs? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
+linux-omap, tony
-Balaji
On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_dma_link_lch
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_burst_mode
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_src_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_set_dma_transfer_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
So, add some stub functions to avoid it.
Reported-by: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..7c8bfdd90a33 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
-extern int omap_request_dma(int dev_id, const char *dev_name,
- void (*callback)(int lch, u16 ch_status, void *data),
- void *data, int *dma_ch);
extern void omap_enable_dma_irq(int ch, u16 irq_bits);
extern void omap_disable_dma_irq(int ch, u16 irq_bits);
-extern void omap_free_dma(int ch);
-extern void omap_start_dma(int lch);
-extern void omap_stop_dma(int lch);
-extern void omap_set_dma_transfer_params(int lch, int data_type,
- int elem_count, int frame_count,
- int sync_mode,
- int dma_trigger, int src_or_dst_synch);
extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
u32 color);
extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode
mode);
-extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
- unsigned long src_start,
- int src_ei, int src_fi);
extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
extern void omap_set_dma_src_data_pack(int lch, int enable);
extern void omap_set_dma_src_burst_mode(int lch,
enum omap_dma_burst_mode burst_mode);
-extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
- unsigned long dest_start,
- int dst_ei, int dst_fi);
extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
extern void omap_set_dma_dest_data_pack(int lch, int enable);
-extern void omap_set_dma_dest_burst_mode(int lch,
- enum omap_dma_burst_mode burst_mode);
extern void omap_set_dma_params(int lch,
struct omap_dma_channel_params *params);
-extern void omap_dma_link_lch(int lch_head, int lch_queue);
extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
extern int omap_set_dma_callback(int lch,
@@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
-extern int omap_request_dma_chain(int dev_id, const char *dev_name,
- void (*callback) (int lch, u16 ch_status,
- void *data),
- int *chain_id, int no_of_chans,
- int chain_mode,
- struct omap_dma_channel_params params);
-extern int omap_free_dma_chain(int chain_id);
extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
int dest_start, int elem_count,
int frame_count, void *callbk_data);
-extern int omap_start_dma_chain_transfers(int chain_id);
-extern int omap_stop_dma_chain_transfers(int chain_id);
extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
extern int omap_get_dma_chain_dst_pos(int chain_id);
extern int omap_get_dma_chain_src_pos(int chain_id);
@@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
extern int omap_dma_chain_status(int chain_id);
#endif
+#ifndef
Re: [PATCH v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 05:34 PM, Marc Kleine-Budde wrote: On 09/09/2014 04:31 PM, Roger Quadros wrote: Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti(). They seem to have been swapped in the usage instances. Can you split this fix into a seperate patch, please. OK. TI's RAMINIT DONE mechanism is buggy and may not always be set after the START bit is set. So add a timeout mechanism to c_can_hw_raminit_wait_ti(). What should happen if the timeout occurs? I'm not sure yet. I will verify if the hardware still works or not in that case. If it doesn't work then we should fail. cheers, -roger -- 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 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 05:34 PM, Nishanth Menon wrote:
On 09/09/2014 09:31 AM, Roger Quadros wrote:
Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti().
They seem to have been swapped in the usage instances.
TI's RAMINIT DONE mechanism is buggy and may not always be
set after the START bit is set. So add a timeout mechanism to
c_can_hw_raminit_wait_ti().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can_platform.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 109cb44..b144e71 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -75,10 +75,18 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32
mask,
u32 val)
{
+int timeout = 0;
/* We look only at the bits of our instance. */
val = mask;
-while ((readl(priv-raminit_ctrlreg) mask) != val)
+while ((readl(priv-raminit_ctrlreg) mask) != val) {
udelay(1);
+timeout++;
+
+if (timeout == 1000) {
How did we come up with this number?
wild guess ;), that it should be set in a few microseconds and the delay is not
too
large.
Till I don't hear from hardware guys, it will remain a guess.
+dev_err(priv-dev-dev, %s: time out\n, __func__);
+break;
lets say we did timeout..
see below:
+}
+}
}
static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
@@ -97,14 +105,14 @@ static void c_can_hw_raminit_ti(const struct c_can_priv
*priv, bool enable)
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl = ~CAN_RAMINIT_DONE_MASK(priv-instance);
-c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+c_can_hw_raminit_wait_ti(priv, mask, ctrl);
if (enable) {
/* Set start bit and wait for the done bit. */
ctrl |= CAN_RAMINIT_START_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
-c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+c_can_hw_raminit_wait_ti(priv, mask, ctrl);
is it possible for us to continue? does it make sense for us to change
that void to a int and handle error cascading?
I will verify this first to check if the hardware works or not in the failing
case.
Considering we never checked for the DONE bit in our earlier TI releases maybe
it works.
But I'll verify and get back.
}
spin_unlock(raminit_lock);
}
cheers,
-roger
--
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 v6 5/7] net: cpsw: Add am33xx MACID readout
* Markus Pargmann m...@pengutronix.de [140908 23:05]:
On Mon, Sep 08, 2014 at 09:51:17AM -0700, Tony Lindgren wrote:
* Markus Pargmann m...@pengutronix.de [140907 10:20]:
This patch adds a function to get the MACIDs from the am33xx SoC
control module registers which hold unique vendor MACIDs. This is only
used if of_get_mac_address() fails to get a valid mac address.
...
@@ -1928,8 +1960,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data
*data,
PHY_ID_FMT, mdio-name, phyid);
mac_addr = of_get_mac_address(slave_node);
- if (mac_addr)
+ if (mac_addr) {
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
+ } else {
+ if (of_machine_is_compatible(ti,am33xx)) {
+ ret = cpsw_am33xx_cm_get_macid(pdev-dev, i,
+ slave_data-mac_addr);
+ if (ret)
+ return ret;
+ }
+ }
slave_data-phy_if = of_get_phy_mode(slave_node);
if (slave_data-phy_if 0) {
Thanks for updating this, this looks more future proof for adding
the dra7 related patch.
For the long run, it probably makes sense to add SoC specific
compatible values such as ti,cpsw-am3350 and so on. Then the
mac address functions can be initialized based on the of_device_id
entry for .data. The wiring is cleary SoC specific here.
The hardware doesn't differ across the SoCs, so I thought it may be
better to keep one compatible and parse the machine compatible for the
MACID location. But different compatible values are also ok.
Yes both will work, and you're right the Ethernet hardware is
the same. I already forgot that we're getting mac address from the
system control module.. And that's really SoC specific so your solution
is better at least for now.
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 v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 09:45 AM, Roger Quadros wrote:
[...]
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val)
+ while ((readl(priv-raminit_ctrlreg) mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
How did we come up with this number?
wild guess ;), that it should be set in a few microseconds and the delay is
not too
large.
Till I don't hear from hardware guys, it will remain a guess.
in cases like these, I suggest using emperical data as point -
example doing some 10,000 iterations of the operation and picking up
the worse case number and double it.
Either way, you need to document the same, else a few years down the
line, when that number is in question, no one will know what it's
basis was..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/12] arm: dts: am4372: Add dcan nodes
From: Afzal Mohammed af...@ti.com
Add dcan nodes.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 8689949..3514d0a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -885,6 +885,28 @@
clock-names = fck;
};
};
+
+ dcan0: can@481cc000 {
+ compatible = bosch,d_can;
+ ti,hwmods = d_can0;
+ clocks = dcan0_fck;
+ clock-names = fck;
+ reg = 0x481cc000 0x2000
+ 0x44e10644 0x4;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ dcan1: can@481d {
+ compatible = bosch,d_can;
+ ti,hwmods = d_can1;
+ clocks = dcan1_fck;
+ clock-names = fck;
+ reg = 0x481d 0x2000
+ 0x44e10644 0x4;
+ interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
};
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/12] arm: dts: am437x-gp: Add dcan support
From: Mugunthan V N mugunthan...@ti.com
Add DCAN support for AM437x GP EVM with both DCAN instances.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index e7ac47f..6d03baa 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -254,6 +254,20 @@
0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
;
};
+
+ dcan0_default: dcan0_default_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
uart1_ctsn.d_can0_tx */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE2) /*
uart1_rtsn.d_can0_rx */
+ ;
+ };
+
+ dcan1_default: dcan1_default_pins {
+ pinctrl-single,pins =
+ 0x180 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
uart1_rxd.d_can1_tx */
+ 0x184 (PIN_INPUT_PULLUP | MUX_MODE2) /*
uart1_txd.d_can1_rx */
+ ;
+ };
};
i2c0 {
@@ -511,3 +525,15 @@
};
};
};
+
+dcan0 {
+ pinctrl-names = default;
+ pinctrl-0 = dcan0_default;
+ status = okay;
+};
+
+dcan1 {
+ pinctrl-names = default;
+ pinctrl-0 = dcan1_default;
+ status = okay;
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/12] ARM: dts: dra7-evm: Add CAN support
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
The second one cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index e03fbf3..d6b9b27 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -171,6 +171,20 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
;
};
+
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins =
+ 0x3d4 (PIN_INPUT | MUX_MODE0) /* dcan1_tx */
+ 0x3d8 (PIN_INPUT | MUX_MODE0) /* dcan1_rx */
+ ;
+ };
+
+ dcan1_pins_sleep: dcan1_pins_sleep {
+ pinctrl-single,pins =
+ 0x3d4 (PIN_INPUT | MUX_MODE15)/* dcan1_tx */
+ 0x3d8 (PIN_INPUT | MUX_MODE15)/* dcan1_rx */
+ ;
+ };
};
i2c1 {
@@ -529,3 +543,10 @@
ti,no-reset-on-init;
ti,no-idle-on-init;
};
+
+dcan1 {
+ status = ok;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = dcan1_pins_default;
+ pinctrl-1 = dcan1_pins_sleep;
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/12] ARM: dts: AM43xx: Add aliases to d_can nodes
The d_can driver expects appropriately named aliases for
the d_can nodes for the RAMINIT control register access.
Provide those, otherwise RAMINIT register won't be configured.
Get's rid of the following messages during boot.
[ 16.419354] c_can_platform 481cc000.can: control memory is not used for
raminit
[ 16.449142] c_can_platform 481d.can: control memory is not used for
raminit
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 3514d0a..a705e50 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -25,6 +25,8 @@
serial0 = uart0;
ethernet0 = cpsw_emac0;
ethernet1 = cpsw_emac1;
+ d_can0 = dcan0;
+ d_can1 = dcan1;
};
cpus {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/12] ARM: dts: am437x-gp-evm: Add pinctrl sleep states for dcan pins
From: Dave Gerlach d-gerl...@ti.com
Define pinctrl sleep states for both dcan0 and dcan1 to place pull downs
on the lines to optimize power savings during suspend.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 6d03baa..ca9e1ab 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -262,12 +262,26 @@
;
};
+ dcan0_sleep: dcan0_sleep_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x17c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
dcan1_default: dcan1_default_pins {
pinctrl-single,pins =
0x180 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
uart1_rxd.d_can1_tx */
0x184 (PIN_INPUT_PULLUP | MUX_MODE2) /*
uart1_txd.d_can1_rx */
;
};
+
+ dcan1_sleep: dcan1_sleep_pins {
+ pinctrl-single,pins =
+ 0x180 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
};
i2c0 {
@@ -527,13 +541,15 @@
};
dcan0 {
- pinctrl-names = default;
+ pinctrl-names = default, sleep;
pinctrl-0 = dcan0_default;
+ pinctrl-1 = dcan0_sleep;
status = okay;
};
dcan1 {
- pinctrl-names = default;
+ pinctrl-names = default, sleep;
pinctrl-0 = dcan1_default;
+ pinctrl-1 = dcan1_sleep;
status = okay;
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/12] ARM: dts: DRA7: Add DCAN nodes
The SoC supports 2 DCAN nodes. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..09d5739 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ d_can0 = dcan1;
+ d_can1 = dcan2;
};
timer {
@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ dcan1: can@481cc000 {
+ compatible = bosch,d_can;
+ ti,hwmods = dcan1;
+ reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within
syscon */
+ ti,raminit-syscon = dra7_ctrl_core;
+ ti,raminit-start-bit = 3;
+ ti,raminit-done-bit = 1;
+ ti,raminit-pulse;
+ interrupts = GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH;
+ clocks = dcan1_sys_clk_mux;
+ status = disabled;
+ };
+
+ dcan2: can@481d {
+ compatible = bosch,d_can;
+ ti,hwmods = dcan2;
+ reg = 0x4848 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within
syscon */
+ ti,raminit-syscon = dra7_ctrl_core;
+ ti,raminit-start-bit = 5;
+ ti,raminit-done-bit = 2;
+ ti,raminit-pulse;
+ interrupts = GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH;
+ clocks = sys_clkin1;
+ status = disabled;
+ };
};
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/12] ARM: dts: dra72-evm: Add CAN support
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
The second one cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 5147023..e5b7172 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,29 @@
};
};
+dra7_pmx_core {
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins =
+ 0x3d4 (PIN_INPUT | MUX_MODE0) /* dcan1_tx */
+ 0x418 (PIN_INPUT | MUX_MODE1) /*
wakeup0.dcan1_rx */
+ ;
+ };
+
+ dcan1_pins_sleep: dcan1_pins_sleep {
+ pinctrl-single,pins =
+ 0x3d4 (PIN_INPUT | MUX_MODE15)/* dcan1_tx.off
*/
+ 0x418 (PIN_INPUT | MUX_MODE15)/* wakeup0.off
*/
+ ;
+ };
+};
+
uart1 {
status = okay;
};
+
+dcan1 {
+ status = ok;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = dcan1_pins_default;
+ pinctrl-1 = dcan1_pins_sleep;
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/12] ARM: dts: dra7: Add syscon regmap for CORE CONTROL area
Display and DCAN drivers use syscon regmap to access some registers
in the CORE control area. Add the syscon regmap node for this
area.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152..370009e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -200,6 +200,11 @@
ti,hwmods = counter_32k;
};
+ dra7_ctrl_core: ctrl_core@4a002000 {
+ compatible = syscon;
+ reg = 0x4a002000 0x6d0;
+ };
+
dra7_ctrl_general: tisyscon@4a002e00 {
compatible = syscon;
reg = 0x4a002e00 0x7c;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/12] ARM: dts: am4372: Add dcan raminit bits
Add RAMINIT specific bits into the DCAN nodes. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/am4372.dtsi | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index d38a0ed..847f41b 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -899,7 +899,10 @@ clocks = dcan0_fck; clock-names = fck; reg = 0x481cc000 0x2000 - 0x44e10644 0x4; + 0x644 0x4; /* index to RAMINIT reg within syscon */ + ti,raminit-syscon = am43xx_control_module; + ti,raminit-start-bit = 0; + ti,raminit-done-bit = 8; interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH; status = disabled; }; @@ -910,7 +913,10 @@ clocks = dcan1_fck; clock-names = fck; reg = 0x481d 0x2000 - 0x44e10644 0x4; + 0x644 0x4; /* index to RAMINIT reg within syscon */ + ti,raminit-syscon = am43xx_control_module; + ti,raminit-start-bit = 1; + ti,raminit-done-bit = 9; interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH; status = disabled; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/12] ARM: dts: TI: Add DCAN support
Hi, These patches add DCAN support for am43xx and dra7xx platforms. We also update the am33xx DCAN nodes to support the driver changes in the RAMINIT mechanism. These patches must go in together with [1] (or its revisions) Patches are available along with dependency [1] patches at g...@github.com:rogerq/linux.git [for-v3.18/dcan-omap] Changelog: v2: - Added vendor prefix ti, to raminit properties - Updated am335x dcan nodes [1] - CAN driver RAMINIT support http://article.gmane.org/gmane.linux.ports.arm.omap/118368 cheers, -roger --- Afzal Mohammed (1): arm: dts: am4372: Add dcan nodes Dave Gerlach (1): ARM: dts: am437x-gp-evm: Add pinctrl sleep states for dcan pins Mugunthan V N (1): arm: dts: am437x-gp: Add dcan support Roger Quadros (9): ARM: dts: dra7: Add syscon regmap for CORE CONTROL area ARM: dts: DRA7: Add DCAN nodes ARM: dts: dra7-evm: Add CAN support ARM: dts: dra72-evm: Add CAN support ARM: dts: AM43xx: Add aliases to d_can nodes ARM: dts: am4372: Add control module syscon node ARM: dts: am4372: Add dcan raminit bits ARM: dts: am33xx: Add control module syscon node ARM: dts: am33xx: Add dcan raminit bits arch/arm/boot/dts/am33xx.dtsi | 19 + arch/arm/boot/dts/am4372.dtsi | 35 +++ arch/arm/boot/dts/am437x-gp-evm.dts | 42 + arch/arm/boot/dts/dra7-evm.dts | 21 +++ arch/arm/boot/dts/dra7.dtsi | 35 +++ arch/arm/boot/dts/dra72-evm.dts | 23 6 files changed, 171 insertions(+), 4 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/12] ARM: dts: am33xx: Add dcan raminit bits
Add RAMINIT specific bits into the DCAN nodes.
Also rename can nodes from d_can to can to be compliant
with the ePAPR specs.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 492c043..0661cdd 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -334,20 +334,26 @@
interrupts = 91;
};
- dcan0: d_can@481cc000 {
+ dcan0: can@481cc000 {
compatible = bosch,d_can;
ti,hwmods = d_can0;
reg = 0x481cc000 0x2000
- 0x44e10644 0x4;
+ 0x644 0x4; /* index to RAMINIT reg within
syscon */
+ ti,raminit-syscon = am33xx_control_module;
+ ti,raminit-start-bit = 0;
+ ti,raminit-done-bit = 8;
interrupts = 52;
status = disabled;
};
- dcan1: d_can@481d {
+ dcan1: can@481d {
compatible = bosch,d_can;
ti,hwmods = d_can1;
reg = 0x481d 0x2000
- 0x44e10644 0x4;
+ 0x644 0x4; /* index to RAMINIT reg within
syscon */
+ ti,raminit-syscon = am33xx_control_module;
+ ti,raminit-start-bit = 1;
+ ti,raminit-done-bit = 9;
interrupts = 55;
status = disabled;
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/12] ARM: dts: am4372: Add control module syscon node
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index a705e50..d38a0ed 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -59,6 +59,11 @@
cache-level = 2;
};
+ am43xx_control_module: control_module@4a002000 {
+ compatible = syscon;
+ reg = 0x44e1 0x7f4;
+ };
+
am43xx_pinmux: pinmux@44e10800 {
compatible = pinctrl-single;
reg = 0x44e10800 0x31c;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/12] ARM: dts: am33xx: Add control module syscon node
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161..492c043 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -83,6 +83,11 @@
};
};
+ am33xx_control_module: control_module@4a002000 {
+ compatible = syscon;
+ reg = 0x44e1 0x7fc;
+ };
+
am33xx_pinmux: pinmux@44e10800 {
compatible = pinctrl-single;
reg = 0x44e10800 0x0238;
--
1.8.3.2
--
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 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 05:51 PM, Nishanth Menon wrote:
On 09/09/2014 09:45 AM, Roger Quadros wrote:
[...]
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val)
+ while ((readl(priv-raminit_ctrlreg) mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
How did we come up with this number?
wild guess ;), that it should be set in a few microseconds and the delay is
not too
large.
Till I don't hear from hardware guys, it will remain a guess.
in cases like these, I suggest using emperical data as point -
example doing some 10,000 iterations of the operation and picking up
the worse case number and double it.
In my tests the bit was either set immediately or never at all.
Not sure if we should increase it further.
Either way, you need to document the same, else a few years down the
line, when that number is in question, no one will know what it's
basis was..
OK. I'll add a comment there.
cheers,
-roger
--
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 1/3] omap-dma: Allow compile-testing omap1_camera driver
* Nishanth Menon n...@ti.com [140909 07:40]:
+linux-omap, tony
-Balaji
On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
ERROR: omap_dma_link_lch
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_burst_mode
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_src_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_request_dma
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_transfer_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_set_dma_dest_params
[drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko]
undefined!
So, add some stub functions to avoid it.
How about just remove that old driver? I doubt it works, and I'm
almost certain nobody has actually tried to use it for many
years. At least I'm not aware of any hardware supported in the
mainline kernel with it. And we're moving things to dma engine
API anyways.
Regards,
Tony
Reported-by: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..7c8bfdd90a33 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
-extern int omap_request_dma(int dev_id, const char *dev_name,
- void (*callback)(int lch, u16 ch_status, void *data),
- void *data, int *dma_ch);
extern void omap_enable_dma_irq(int ch, u16 irq_bits);
extern void omap_disable_dma_irq(int ch, u16 irq_bits);
-extern void omap_free_dma(int ch);
-extern void omap_start_dma(int lch);
-extern void omap_stop_dma(int lch);
-extern void omap_set_dma_transfer_params(int lch, int data_type,
-int elem_count, int frame_count,
-int sync_mode,
-int dma_trigger, int src_or_dst_synch);
extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
u32 color);
extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode
mode);
extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode
mode);
-extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
- unsigned long src_start,
- int src_ei, int src_fi);
extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
extern void omap_set_dma_src_data_pack(int lch, int enable);
extern void omap_set_dma_src_burst_mode(int lch,
enum omap_dma_burst_mode burst_mode);
-extern void omap_set_dma_dest_params(int lch, int dest_port, int
dest_amode,
-unsigned long dest_start,
-int dst_ei, int dst_fi);
extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
extern void omap_set_dma_dest_data_pack(int lch, int enable);
-extern void omap_set_dma_dest_burst_mode(int lch,
-enum omap_dma_burst_mode burst_mode);
extern void omap_set_dma_params(int lch,
struct omap_dma_channel_params *params);
-extern void omap_dma_link_lch(int lch_head, int lch_queue);
extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
extern int omap_set_dma_callback(int lch,
@@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
-extern int omap_request_dma_chain(int dev_id, const char *dev_name,
- void (*callback) (int lch, u16 ch_status,
- void *data),
- int *chain_id, int no_of_chans,
- int chain_mode,
- struct omap_dma_channel_params params);
-extern int omap_free_dma_chain(int chain_id);
extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
int dest_start, int elem_count,
int frame_count, void *callbk_data);
-extern int omap_start_dma_chain_transfers(int chain_id);
-extern int
Re: [PATCH v2 02/12] ARM: dts: DRA7: Add DCAN nodes
On 09/09/2014 04:55 PM, Roger Quadros wrote:
The SoC supports 2 DCAN nodes. Add them.
I think you should put the device-tree ml for DT related patches on Cc.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..09d5739 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ d_can0 = dcan1;
+ d_can1 = dcan2;
};
timer {
@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ dcan1: can@481cc000 {
+ compatible = bosch,d_can;
+ ti,hwmods = dcan1;
+ reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within
syscon */
Putting the offset within the syscon here doesn't look good.
+ ti,raminit-syscon = dra7_ctrl_core;
Why not add it as a second parameter to the ti,raminit-syscon instead?
+ ti,raminit-start-bit = 3;
+ ti,raminit-done-bit = 1;
+ ti,raminit-pulse;
+ interrupts = GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH;
+ clocks = dcan1_sys_clk_mux;
+ status = disabled;
+ };
+
+ dcan2: can@481d {
+ compatible = bosch,d_can;
+ ti,hwmods = dcan2;
+ reg = 0x4848 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within
syscon */
+ ti,raminit-syscon = dra7_ctrl_core;
+ ti,raminit-start-bit = 5;
+ ti,raminit-done-bit = 2;
+ ti,raminit-pulse;
+ interrupts = GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH;
+ clocks = sys_clkin1;
+ status = disabled;
+ };
};
};
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 02/12] ARM: dts: DRA7: Add DCAN nodes
On 09/09/2014 05:04 PM, Marc Kleine-Budde wrote:
On 09/09/2014 04:55 PM, Roger Quadros wrote:
The SoC supports 2 DCAN nodes. Add them.
I think you should put the device-tree ml for DT related patches on Cc.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..09d5739 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+d_can0 = dcan1;
+d_can1 = dcan2;
};
timer {
@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+dcan1: can@481cc000 {
+compatible = bosch,d_can;
+ti,hwmods = dcan1;
+reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within
syscon */
Putting the offset within the syscon here doesn't look good.
+ti,raminit-syscon = dra7_ctrl_core;
Why not add it as a second parameter to the ti,raminit-syscon instead?
./drivers/power/reset/keystone-reset.c does this.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 06/12] ARM: dts: AM43xx: Add aliases to d_can nodes
On 09/09/2014 04:55 PM, Roger Quadros wrote: The d_can driver expects appropriately named aliases for the d_can nodes for the RAMINIT control register access. Provide those, otherwise RAMINIT register won't be configured. Get's rid of the following messages during boot. With your patch set this is not true anymore, is it? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 05/12] arm: dts: am4372: Add dcan nodes
On 09/09/2014 04:55 PM, Roger Quadros wrote:
From: Afzal Mohammed af...@ti.com
Add dcan nodes.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 8689949..3514d0a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -885,6 +885,28 @@
clock-names = fck;
};
};
+
+ dcan0: can@481cc000 {
+ compatible = bosch,d_can;
+ ti,hwmods = d_can0;
+ clocks = dcan0_fck;
+ clock-names = fck;
+ reg = 0x481cc000 0x2000
+ 0x44e10644 0x4;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
Where are the syscon phandles?
+ status = disabled;
+ };
+
+ dcan1: can@481d {
+ compatible = bosch,d_can;
+ ti,hwmods = d_can1;
+ clocks = dcan1_fck;
+ clock-names = fck;
+ reg = 0x481d 0x2000
+ 0x44e10644 0x4;
+ interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
};
};
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
Em Tue, 9 Sep 2014 15:41:58 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote: We want to be able to COMPILE_TEST the omap1_camera driver. It compiles fine, but it fails linkediting: ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_dma_link_lch [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_burst_mode [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_src_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_transfer_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! So, add some stub functions to avoid it. The real answer to this is to find someone who still uses it, and convert it to the DMA engine API. If there's no users, the driver might as well be killed off. Hmm... it seems that there are still several drivers still relying on the functions declared at: omap-dma.h: $ grep extern include/linux/omap-dma.h |perl -ne 'print $1\n if (m/extern\s\S+\s(.*)\(/)' funcs git grep -f funcs -l arch/arm/mach-omap1/pm.c arch/arm/mach-omap2/pm24xx.c arch/arm/plat-omap/dma.c drivers/dma/omap-dma.c drivers/media/platform/omap/omap_vout_vrfb.c drivers/media/platform/omap3isp/isphist.c drivers/media/platform/soc_camera/omap1_camera.c drivers/mtd/onenand/omap2.c drivers/usb/gadget/udc/omap_udc.c drivers/usb/musb/tusb6010_omap.c drivers/video/fbdev/omap/omapfb_main.c include/linux/omap-dma.h Perhaps we can remove the header and mark all the above as BROKEN. If nobody fixes, we can strip all of them from the Kernel. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
by splitting the driver into a core module and a thin arch-specific
operations module.
(In practice only the OMAP2+ module omap-iommu2 is implemented, but
let's not denigrate the effort.)
The arch-specific operations module registers itself with the OMAP IOMMU
core module at initialization time. This initializes a module global
arch-specific operations pointer, used at runtime by the IOMMU
instances.
This scheme causes several issues. In addition to making it impossible
to support different OMAP IOMMU types in a single system (which in all
fairness is quite unlikely to happen), it also causes initialization
ordering issues by requiring the arch-specific operations module to be
loaded before any IOMMU user. This results in a probe breakage with the
OMAP3 ISP driver when not compiled as a module.
Fix the problem by inverting the dependency. Instead of having the
omap-iommu2 module register itself to iommu-omap, make the iommu-omap
retrieve the omap-iommu2 operations structure directly when probing the
IOMMU device. This ensures that a probed IOMMU will always have valid
arch-specific operations.
As the arch-specific operations pointer is now initialized at probe
time, this change requires turning it from a global variable into a
per-device variable.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu-debug.c | 6 ++-
drivers/iommu/omap-iommu.c | 94 ++--
drivers/iommu/omap-iommu.h | 10 -
drivers/iommu/omap-iommu2.c | 18 +---
4 files changed, 45 insertions(+), 83 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 531658d..35a2c3a 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -33,7 +33,9 @@ static struct dentry *iommu_debug_root;
static ssize_t debug_read_ver(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- u32 ver = omap_iommu_arch_version();
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ u32 ver = omap_iommu_arch_version(obj);
char buf[MAXCOLUMN], *p = buf;
p += sprintf(p, H/W version: %d.%d\n, (ver 4) 0xf , ver 0xf);
@@ -117,7 +119,7 @@ static ssize_t debug_write_pagetable(struct file *file,
return -EINVAL;
}
- omap_iotlb_cr_to_e(cr, e);
+ omap_iotlb_cr_to_e(obj, cr, e);
err = omap_iopgtable_store_entry(obj, e);
if (err)
dev_err(obj-dev, %s: fail to store cr\n, __func__);
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index df579f8..192c367 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -76,45 +76,10 @@ struct iotlb_lock {
short vict;
};
-/* accommodate the difference between omap1 and omap2/3 */
-static const struct iommu_functions *arch_iommu;
-
static struct platform_driver omap_iommu_driver;
static struct kmem_cache *iopte_cachep;
/**
- * omap_install_iommu_arch - Install archtecure specific iommu functions
- * @ops: a pointer to architecture specific iommu functions
- *
- * There are several kind of iommu algorithm(tlb, pagetable) among
- * omap series. This interface installs such an iommu algorighm.
- **/
-int omap_install_iommu_arch(const struct iommu_functions *ops)
-{
- if (arch_iommu)
- return -EBUSY;
-
- arch_iommu = ops;
- return 0;
-}
-EXPORT_SYMBOL_GPL(omap_install_iommu_arch);
-
-/**
- * omap_uninstall_iommu_arch - Uninstall archtecure specific iommu functions
- * @ops: a pointer to architecture specific iommu functions
- *
- * This interface uninstalls the iommu algorighm installed previously.
- **/
-void omap_uninstall_iommu_arch(const struct iommu_functions *ops)
-{
- if (arch_iommu != ops)
- pr_err(%s: not your arch\n, __func__);
-
- arch_iommu = NULL;
-}
-EXPORT_SYMBOL_GPL(omap_uninstall_iommu_arch);
-
-/**
* omap_iommu_save_ctx - Save registers for pm off-mode support
* @dev: client device
**/
@@ -122,7 +87,7 @@ void omap_iommu_save_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-save_ctx(obj);
+ obj-arch_iommu-save_ctx(obj);
}
EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
@@ -134,16 +99,16 @@ void omap_iommu_restore_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-restore_ctx(obj);
+ obj-arch_iommu-restore_ctx(obj);
}
EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
/**
* omap_iommu_arch_version - Return running iommu arch version
**/
-u32 omap_iommu_arch_version(void)
+u32 omap_iommu_arch_version(struct omap_iommu *obj)
{
- return arch_iommu-version;
+ return obj-arch_iommu-version;
}
[PATCH 0/2] OMAP IOMMU cleanups
Hello, Those two patches clean up the OMAP IOMMU driver. Please see individual commit messages for more information. Laurent Pinchart (2): iommu/omap: Reverse dependency between omap-iommu and omap-iommu2 iommu/omap: Remove omap_iommu unused owner field drivers/iommu/omap-iommu-debug.c | 6 ++- drivers/iommu/omap-iommu.c | 103 --- drivers/iommu/omap-iommu.h | 11 +++-- drivers/iommu/omap-iommu2.c | 18 +-- 4 files changed, 44 insertions(+), 94 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] iommu/omap: Remove omap_iommu unused owner field
The owner field is never set. Remove it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 11 ---
drivers/iommu/omap-iommu.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 192c367..fdfe732 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -861,20 +861,11 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd)
goto err_enable;
flush_iotlb_all(obj);
- if (!try_module_get(obj-owner)) {
- dev_err(obj-dev, %s: can't get owner\n, __func__);
- err = -ENODEV;
- goto err_module;
- }
-
spin_unlock(obj-iommu_lock);
dev_dbg(obj-dev, %s: %s\n, __func__, obj-name);
return obj;
-err_module:
- if (obj-refcount == 1)
- iommu_disable(obj);
err_enable:
obj-refcount--;
spin_unlock(obj-iommu_lock);
@@ -895,8 +886,6 @@ static void omap_iommu_detach(struct omap_iommu *obj)
if (--obj-refcount == 0)
iommu_disable(obj);
- module_put(obj-owner);
-
obj-iopgd = NULL;
spin_unlock(obj-iommu_lock);
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 7a90800..2c3b85c 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -28,7 +28,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
- struct module *owner;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/5] OMAP Mailbox framework adoption DT support
Hi Tony, On 09/08/2014 09:52 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140908 16:21]: * Suman Anna s-a...@ti.com [140729 17:37]: Hi, This is an updated version of the OMAP Mailbox framework adoption DT support series, refreshed to work with the v9 version of the mailbox framework [1] from Jassi Brar while also addressing some minor review comments. Detailed changes are summarized below. Patches are based on 3.16-rc2. Sorry for the delay, just noticed that I'm supposed to queue these too. I'll queue these into omap-for-v3.18/mailbox against v3.17-rc1 and will probably also merge it into omap-for-v3.18/dt as well. Actually this is not compiling and seems to probably miss the dependencies from Jassi, so dropping the branch. The last 2 patches which is the framework adoption portion needs the framework patches from Jassi (as stated in the cover letter). I will ping on the framework thread to see if it is making it into 3.18. In any case, we should be able to take the first three patches (2 in drivers and 1 for DT) - they are independent of the framework and also are dependencies for the framework adoption patches. Anyways, since it seems you need to repost this again, please repost the DT changes separately from the driver changes. Yeah, the other two dependent series are merged for 3.17, so these are the only patches remaining. I just need to repost them on a 3.17-rc, but there are no changes required (even with v10 of the framework). So given above, do you want me to split the first 3 (there is one DT patch) and post them so that they can be merged for 3.18? regards Suman -- 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 2/3] kbuild: remove unnecessary variable initializaions
On Tue, Sep 9, 2014 at 6:26 AM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Clearing obj-y, obj-m, obj-n, obj- in each Makefile is a useless habit. They are non-exported variables; therefore they are always empty whenever descending into each subdirectory. (Moreorver, obj-y and obj-m are also set to empty at the beginning of scripts/Makefile.build) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Peter Foley pefol...@pefoley.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP5+: Reuse OMAP4 PM code for OMAP5 and DRA7
OMAP4, OMAP5 and DRA7 share a lot of common logic and data structures. These have been enabled in the previous patches, however, this also means that OMAP5 or DRA7 only builds also need to build OMAP4 logic. Update to reuse OMAP4 logic. This fixes the 'undefined reference to 'omap4_pm_init_early'' in OMAP5 or DRA7 only builds. Fixes: 6af16a1dac5465c (ARM: DRA7: Add hook in SoC initcalls to enable pm initialization) Fixes: 628ed4717000789 (ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization) Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- This fixes the regression with randconfig that Tony reported with omap-for-v3.18/soc branch. Tested with CONFIG_ARCH_OMAP2, CONFIG_ARCH_OMAP3, CONFIG_ARCH_OMAP4, CONFIG_SOC_OMAP5, CONFIG_SOC_AM33XX, CONFIG_SOC_AM43XX, CONFIG_SOC_DRA7XX only builds. arch/arm/mach-omap2/Makefile | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 69bbcba..d9dd99c 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -87,9 +87,10 @@ ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o -obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o -obj-$(CONFIG_SOC_DRA7XX) += omap-mpuss-lowpower.o +omap-4-5-pm-common = pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common) +obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-pm-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-pm-common) obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o @@ -102,7 +103,10 @@ endif ifeq ($(CONFIG_CPU_IDLE),y) obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o -obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o +omap-4-5-idle-common = cpuidle44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-idle-common) +obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-idle-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-idle-common) endif # PRCM -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
Em Tue, 09 Sep 2014 12:36:54 -0300 Mauro Carvalho Chehab m.che...@samsung.com escreveu: Em Tue, 9 Sep 2014 15:41:58 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote: We want to be able to COMPILE_TEST the omap1_camera driver. It compiles fine, but it fails linkediting: ERROR: omap_stop_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_start_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_dma_link_lch [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_burst_mode [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_src_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_request_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_transfer_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_set_dma_dest_params [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! ERROR: omap_free_dma [drivers/media/platform/soc_camera/omap1_camera.ko] undefined! So, add some stub functions to avoid it. The real answer to this is to find someone who still uses it, and convert it to the DMA engine API. If there's no users, the driver might as well be killed off. Hmm... it seems that there are still several drivers still relying on the functions declared at: omap-dma.h: $ grep extern include/linux/omap-dma.h |perl -ne 'print $1\n if (m/extern\s\S+\s(.*)\(/)' funcs git grep -f funcs -l arch/arm/mach-omap1/pm.c arch/arm/mach-omap2/pm24xx.c arch/arm/plat-omap/dma.c drivers/dma/omap-dma.c drivers/media/platform/omap/omap_vout_vrfb.c drivers/media/platform/omap3isp/isphist.c drivers/media/platform/soc_camera/omap1_camera.c drivers/mtd/onenand/omap2.c drivers/usb/gadget/udc/omap_udc.c drivers/usb/musb/tusb6010_omap.c drivers/video/fbdev/omap/omapfb_main.c include/linux/omap-dma.h Perhaps we can remove the header and mark all the above as BROKEN. If nobody fixes, we can strip all of them from the Kernel. Are all the functions declared at omap-dma.h part of the old DMA API that should be deprecated? If so, it seems that the OMAP2 and OMAP3 also depends on this thing, as all the PM code for OMAP depends on the functions declared inside omap-dma.h, and marking them as BROKEN causes compilation to failure: arch/arm/mach-omap2/built-in.o: In function `omap3_save_scratchpad_contents': :(.text+0x798): undefined reference to `omap3_restore_3630' :(.text+0x7a8): undefined reference to `omap3_restore' :(.text+0x7ac): undefined reference to `omap3_restore_es3' arch/arm/mach-omap2/built-in.o: In function `omap3_sram_restore_context': :(.text+0x925c): undefined reference to `omap_push_sram_idle' arch/arm/mach-omap2/built-in.o: In function `option_set': :(.text+0xc15c): undefined reference to `omap3_pm_off_mode_enable' arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_set': :(.text+0xc1a0): undefined reference to `omap3_pm_set_suspend_state' arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_get': :(.text+0xc1e4): undefined reference to `omap3_pm_get_suspend_state' arch/arm/mach-omap2/built-in.o: In function `omap3_enter_idle_bm': :(.text+0xc7ec): undefined reference to `omap_sram_idle' :(.text+0xc848): undefined reference to `pm34xx_errata' arch/arm/mach-omap2/built-in.o: In function `omap2420_init_late': :(.init.text+0xf64): undefined reference to `omap2_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap2430_init_late': :(.init.text+0x1024): undefined reference to `omap2_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3_init_late': :(.init.text+0x1248): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3430_init_late': :(.init.text+0x1264): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap35xx_init_late': :(.init.text+0x1280): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `omap3630_init_late': :(.init.text+0x129c): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o: In function `am35xx_init_late': :(.init.text+0x12b8): undefined reference to `omap3_pm_init' arch/arm/mach-omap2/built-in.o::(.init.text+0x12d4): more undefined references to `omap3_pm_init' follow This was compiled with allmodconfig on arm, with COMPILE_TEST disabled (a few sub-archs disabled too), to avoid spurious unrelated compilation issues). Am I missing something? BTW, CONFIG_PM is auto-selected by ARCH_OMAP3. And those are the functions that the OMAP3 code uses from omap-dma.h: arch/arm/mach-omap2/pm34xx.c:92:2: error: implicit declaration of function ‘omap_dma_global_context_save’ [-Werror=implicit-function-declaration] arch/arm/mach-omap2/pm34xx.c:103:2: error:
Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
On 09/08/2014 08:33 PM, Frans Klaver wrote: Thanks. I'll give it a spin on Wednesday. Could you please pull the upcoming v9 first? git://git.breakpoint.cc/bigeasy/linux.git uart_v9_pre1 This solves a few of my am335x related issues. The problem that the uart freezes on beagle board xm is still there. From what I can say is that the DMA transfer is started but not completed and I can't reproduce it on dra7xx Thanks, Frans Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Ohad, On 09/09/2014 05:31 AM, Ohad Ben-Cohen wrote: On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman khil...@linaro.org wrote: To me, it's not terribly clear how you made the split between this PM core code an the remoteproc code. In the changelog for the remoteproc patch, it states it's to load the firmware for and boot the wkup_m3. But, while parts of the IPC are here in pm33xx.c, parts of the IPC are also inside the remoteproc driver, so I'm quite curious if that's OK with the remoteproc maintainers. Either way, please make it clearer how and why you made the split, and please isolate the wkup_m3 IPC/protocol from this code. Think of people wanting to rework/extend the wkup_m3 firmware. They shouldn't be messing around in here, but rather inside a driver specificaly for the wkup_m3. I haven't looked at the code very thoroughly yet, but generally a remoteproc driver should only implement the three start/stop/kick rproc_ops, and then register them via the remoteproc framework. Exposing additional API directly from that driver isn't something we immediately want to accept. If relevant, we would generally prefer to extend remoteproc instead, so other platform-specific drivers could utilize that functionality as well. Or rpmsg - if we're missing some IPC functionality. The WkupM3 cannot access DDR, and so we don't intend to use rpmsg. The IPC with wkup_m3 is usually one of the last steps for putting the SoC into a desired low-power state either during suspend or cpuidle, and the communication uses a bank of fixed registers. The .kick is specific to virtio-based communication, and so this is not gonna be used. If you can take a closer look at the wkup_m3 remoteproc driver and give your comments, then we can plan on the next steps. Especially as there are also pieces pertaining to the PM layer knowing the WkupM3 has been loaded and booted. There are already some pending comments on code fragments from Santosh and myself, but let us know your inputs on the integration aspects on PM, remoteproc and IPC with WkupM3. regards Suman -- 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 v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
Kevin/Ohad, On 09/09/2014 02:59 PM, Suman Anna wrote: Hi Ohad, On 09/09/2014 05:31 AM, Ohad Ben-Cohen wrote: On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman khil...@linaro.org wrote: To me, it's not terribly clear how you made the split between this PM core code an the remoteproc code. In the changelog for the remoteproc patch, it states it's to load the firmware for and boot the wkup_m3. But, while parts of the IPC are here in pm33xx.c, parts of the IPC are also inside the remoteproc driver, so I'm quite curious if that's OK with the remoteproc maintainers. Either way, please make it clearer how and why you made the split, and please isolate the wkup_m3 IPC/protocol from this code. Think of people wanting to rework/extend the wkup_m3 firmware. They shouldn't be messing around in here, but rather inside a driver specificaly for the wkup_m3. I haven't looked at the code very thoroughly yet, but generally a remoteproc driver should only implement the three start/stop/kick rproc_ops, and then register them via the remoteproc framework. Exposing additional API directly from that driver isn't something we immediately want to accept. If relevant, we would generally prefer to extend remoteproc instead, so other platform-specific drivers could utilize that functionality as well. Or rpmsg - if we're missing some IPC functionality. The WkupM3 cannot access DDR, and so we don't intend to use rpmsg. The IPC with wkup_m3 is usually one of the last steps for putting the SoC into a desired low-power state either during suspend or cpuidle, and the communication uses a bank of fixed registers. The .kick is specific to virtio-based communication, and so this is not gonna be used. If you can take a closer look at the wkup_m3 remoteproc driver and give your comments, then we can plan on the next steps. Especially as there are also pieces pertaining to the PM layer knowing the WkupM3 has been loaded and booted. There are already some pending comments on code fragments from Santosh and myself, but let us know your inputs on the integration aspects on PM, remoteproc and IPC with WkupM3. The split was defined by putting all the application specific (to the firmware in use) code in the platform pm code while trying to keep all the IPC code within the wkup_m3_rproc driver. The exposed API is definitely heavily biased towards the intended use-case, but the CM3 was designed with this exact purpose in mind and not much else, and due to the limited IPC registers we have to work with there isn't a whole lot of flexibility. Only IPC reg 0 is always used as the resume address, the usage of the other registers is defined by the firmware and pm code. Just as a refresher for those not familiar with it, the IPC mechanism works like this: we load the ipc registers (8 for am33xx, 16 for am43xx) with any information we want to communicate to the CM3, then we make a dummy write to the Mailbox which triggers an interrupt on the CM3, the CM3 does what it needs to with the info passed in the IPC regs and writes anything it wants to communicate back to these registers, and then triggers a different interrupt (not related to mailbox) to let the MPU know it is done. It's kind of a mess so I figured one driver was the best way to encapsulate it all, and I still had to introduce callbacks within the wkup_m3_rproc driver so it could let the pm code know when the FW loaded (to actually enable pm) and when an interrupt was received from the wkup_m3 (so the pm code can process the response). As Suman stated, this sequence is part of the suspend path and also will be part of the lower c-states for cpuidle, so we need something fast and lightweight. RPMsg is way more than we need and it doesn't really fit the use case, so I'm not sure what makes the most sense, extending remoteproc in some way to support IPC communication like described above or leaving the basic FW loading functionality in place in remoteproc but moving the IPC and wkup_m3 functionality back into the platform pm33xx code as it's so specific to that use-case anyway. Regards, Dave regards Suman -- 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 v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
Dave Gerlach d-gerl...@ti.com writes: Kevin/Ohad, On 09/09/2014 02:59 PM, Suman Anna wrote: Hi Ohad, On 09/09/2014 05:31 AM, Ohad Ben-Cohen wrote: On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman khil...@linaro.org wrote: To me, it's not terribly clear how you made the split between this PM core code an the remoteproc code. In the changelog for the remoteproc patch, it states it's to load the firmware for and boot the wkup_m3. But, while parts of the IPC are here in pm33xx.c, parts of the IPC are also inside the remoteproc driver, so I'm quite curious if that's OK with the remoteproc maintainers. Either way, please make it clearer how and why you made the split, and please isolate the wkup_m3 IPC/protocol from this code. Think of people wanting to rework/extend the wkup_m3 firmware. They shouldn't be messing around in here, but rather inside a driver specificaly for the wkup_m3. I haven't looked at the code very thoroughly yet, but generally a remoteproc driver should only implement the three start/stop/kick rproc_ops, and then register them via the remoteproc framework. Exposing additional API directly from that driver isn't something we immediately want to accept. If relevant, we would generally prefer to extend remoteproc instead, so other platform-specific drivers could utilize that functionality as well. Or rpmsg - if we're missing some IPC functionality. The WkupM3 cannot access DDR, and so we don't intend to use rpmsg. The IPC with wkup_m3 is usually one of the last steps for putting the SoC into a desired low-power state either during suspend or cpuidle, and the communication uses a bank of fixed registers. The .kick is specific to virtio-based communication, and so this is not gonna be used. If you can take a closer look at the wkup_m3 remoteproc driver and give your comments, then we can plan on the next steps. Especially as there are also pieces pertaining to the PM layer knowing the WkupM3 has been loaded and booted. There are already some pending comments on code fragments from Santosh and myself, but let us know your inputs on the integration aspects on PM, remoteproc and IPC with WkupM3. The split was defined by putting all the application specific (to the firmware in use) code in the platform pm code while trying to keep all the IPC code within the wkup_m3_rproc driver. I don't even see that split. I see the platform PM code directly setting IPC register values, but then rproc driver actually sends the mailbox command. The exposed API is definitely heavily biased towards the intended use-case, Maybe if the API was actually documented, it would be easier for us to review it. but the CM3 was designed with this exact purpose in mind and not much else, and due to the limited IPC registers we have to work with there isn't a whole lot of flexibility. Only IPC reg 0 is always used as the resume address, the usage of the other registers is defined by the firmware and pm code. Just as a refresher for those not familiar with it, the IPC mechanism works like this: we load the ipc registers (8 for am33xx, 16 for am43xx) with any information we want to communicate to the CM3, OK, and this happens currently in the platform PM code, right? then we make a dummy write to the Mailbox which triggers an interrupt on the CM3, the CM3 does what it needs to with the info passed in the IPC regs and writes anything it wants to communicate back to these registers, and then triggers a different interrupt (not related to mailbox) to let the MPU know it is done. And this part happens in the rproc driver, right? It's kind of a mess so I figured one driver was the best way to encapsulate it all, So where is this one driver that encapsulates it all? and I still had to introduce callbacks within the wkup_m3_rproc driver so it could let the pm code know when the FW loaded (to actually enable pm) and when an interrupt was received from the wkup_m3 (so the pm code can process the response). As Suman stated, this sequence is part of the suspend path and also will be part of the lower c-states for cpuidle, so we need something fast and lightweight. RPMsg is way more than we need and it doesn't really fit the use case, so I'm not sure what makes the most sense, extending remoteproc in some way to support IPC communication like described above or leaving the basic FW loading functionality in place in remoteproc but moving the IPC and wkup_m3 functionality back into the platform pm33xx code as it's so specific to that use-case anyway. I'm not advocating for using rpmsg (anymore). But I dont' think shoving your rpmsg-lite IPC into your rproc driver is the right answer either (and Ohad's repsonse confirmed my suspicion.) What I think you need to do (and what I've recommended at least once in earlier reviews) put all the (non-rproc) wkup_m3 IPC into into one driver and create a well-described, well-documented API that the
Re: [PATCH 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
Hi Laurent,
On 09/09/2014 10:45 AM, Laurent Pinchart wrote:
The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
by splitting the driver into a core module and a thin arch-specific
operations module.
(In practice only the OMAP2+ module omap-iommu2 is implemented, but
let's not denigrate the effort.)
Thank you for the patch. I had something similar in my list of cleanup
TODO items on the OMAP IOMMU driver, but I was intending to cut down
more and consolidate the omap-iommu.c and omap-iommu2.c files into a
single one.
This had been the case from the introduction of the driver going back to
v2.6.30, and OMAP1 was never added and I doubt it would be added anytime
in the foreseeable future.
The arch-specific operations module registers itself with the OMAP IOMMU
core module at initialization time. This initializes a module global
arch-specific operations pointer, used at runtime by the IOMMU
instances.
This scheme causes several issues. In addition to making it impossible
to support different OMAP IOMMU types in a single system (which in all
fairness is quite unlikely to happen),
Yep, except for a few enhancements (like reporting Fault PC address on
OMAP4 DSPs, and dropping both endianness support), the core IOMMU
functionality hasn't changed much between OMAP2 and the latest OMAP4+
SoCs. So, my plan was to completely get rid of the iommu_functions (it
also eliminates the need for exporting most of the OMAP IOMMU API). So
while I am ok with the current patch, I prefer consolidation than
keeping the scalability alive, it can always be added if a need for that
arises. What do you think?
it also causes initialization
ordering issues by requiring the arch-specific operations module to be
loaded before any IOMMU user. This results in a probe breakage with the
OMAP3 ISP driver when not compiled as a module.
This can be fixed if we make the current omap-iommu2.c as a
subsys_initcall as well, right?
regards
Suman
Fix the problem by inverting the dependency. Instead of having the
omap-iommu2 module register itself to iommu-omap, make the iommu-omap
retrieve the omap-iommu2 operations structure directly when probing the
IOMMU device. This ensures that a probed IOMMU will always have valid
arch-specific operations.
As the arch-specific operations pointer is now initialized at probe
time, this change requires turning it from a global variable into a
per-device variable.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu-debug.c | 6 ++-
drivers/iommu/omap-iommu.c | 94
++--
drivers/iommu/omap-iommu.h | 10 -
drivers/iommu/omap-iommu2.c | 18 +---
4 files changed, 45 insertions(+), 83 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c
index 531658d..35a2c3a 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -33,7 +33,9 @@ static struct dentry *iommu_debug_root;
static ssize_t debug_read_ver(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- u32 ver = omap_iommu_arch_version();
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ u32 ver = omap_iommu_arch_version(obj);
char buf[MAXCOLUMN], *p = buf;
p += sprintf(p, H/W version: %d.%d\n, (ver 4) 0xf , ver 0xf);
@@ -117,7 +119,7 @@ static ssize_t debug_write_pagetable(struct file *file,
return -EINVAL;
}
- omap_iotlb_cr_to_e(cr, e);
+ omap_iotlb_cr_to_e(obj, cr, e);
err = omap_iopgtable_store_entry(obj, e);
if (err)
dev_err(obj-dev, %s: fail to store cr\n, __func__);
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index df579f8..192c367 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -76,45 +76,10 @@ struct iotlb_lock {
short vict;
};
-/* accommodate the difference between omap1 and omap2/3 */
-static const struct iommu_functions *arch_iommu;
-
static struct platform_driver omap_iommu_driver;
static struct kmem_cache *iopte_cachep;
/**
- * omap_install_iommu_arch - Install archtecure specific iommu functions
- * @ops: a pointer to architecture specific iommu functions
- *
- * There are several kind of iommu algorithm(tlb, pagetable) among
- * omap series. This interface installs such an iommu algorighm.
- **/
-int omap_install_iommu_arch(const struct iommu_functions *ops)
-{
- if (arch_iommu)
- return -EBUSY;
-
- arch_iommu = ops;
- return 0;
-}
-EXPORT_SYMBOL_GPL(omap_install_iommu_arch);
-
-/**
- * omap_uninstall_iommu_arch - Uninstall archtecure specific iommu functions
- * @ops: a pointer to architecture specific iommu functions
- *
- * This interface uninstalls the iommu algorighm
Re: [PATCH 2/2] iommu/omap: Remove omap_iommu unused owner field
Hi Laurent,
On 09/09/2014 10:45 AM, Laurent Pinchart wrote:
The owner field is never set. Remove it.
Thanks, this seems to have been dead code since the days OMAP IOMMU has
been converted from building as modules to built-in as part of the IOMMU
API adoption. So,
Acked-by: Suman Anna s-a...@ti.com
regards
Suman
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 11 ---
drivers/iommu/omap-iommu.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 192c367..fdfe732 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -861,20 +861,11 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd)
goto err_enable;
flush_iotlb_all(obj);
- if (!try_module_get(obj-owner)) {
- dev_err(obj-dev, %s: can't get owner\n, __func__);
- err = -ENODEV;
- goto err_module;
- }
-
spin_unlock(obj-iommu_lock);
dev_dbg(obj-dev, %s: %s\n, __func__, obj-name);
return obj;
-err_module:
- if (obj-refcount == 1)
- iommu_disable(obj);
err_enable:
obj-refcount--;
spin_unlock(obj-iommu_lock);
@@ -895,8 +886,6 @@ static void omap_iommu_detach(struct omap_iommu *obj)
if (--obj-refcount == 0)
iommu_disable(obj);
- module_put(obj-owner);
-
obj-iopgd = NULL;
spin_unlock(obj-iommu_lock);
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 7a90800..2c3b85c 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -28,7 +28,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
- struct module *owner;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
--
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 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
Hi Suman, On Tuesday 09 September 2014 16:33:11 Suman Anna wrote: On 09/09/2014 10:45 AM, Laurent Pinchart wrote: The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants by splitting the driver into a core module and a thin arch-specific operations module. (In practice only the OMAP2+ module omap-iommu2 is implemented, but let's not denigrate the effort.) Thank you for the patch. I had something similar in my list of cleanup TODO items on the OMAP IOMMU driver, but I was intending to cut down more and consolidate the omap-iommu.c and omap-iommu2.c files into a single one. This had been the case from the introduction of the driver going back to v2.6.30, and OMAP1 was never added and I doubt it would be added anytime in the foreseeable future. The arch-specific operations module registers itself with the OMAP IOMMU core module at initialization time. This initializes a module global arch-specific operations pointer, used at runtime by the IOMMU instances. This scheme causes several issues. In addition to making it impossible to support different OMAP IOMMU types in a single system (which in all fairness is quite unlikely to happen), Yep, except for a few enhancements (like reporting Fault PC address on OMAP4 DSPs, and dropping both endianness support), the core IOMMU functionality hasn't changed much between OMAP2 and the latest OMAP4+ SoCs. So, my plan was to completely get rid of the iommu_functions (it also eliminates the need for exporting most of the OMAP IOMMU API). So while I am ok with the current patch, I prefer consolidation than keeping the scalability alive, it can always be added if a need for that arises. What do you think? I agree with your approach, but in the meantime we have a problem to solve. How about applying this patch now (it goes in the right direction anyway), and then removing the iommu functions when you will have time ? it also causes initialization ordering issues by requiring the arch-specific operations module to be loaded before any IOMMU user. This results in a probe breakage with the OMAP3 ISP driver when not compiled as a module. This can be fixed if we make the current omap-iommu2.c as a subsys_initcall as well, right? regards Suman Fix the problem by inverting the dependency. Instead of having the omap-iommu2 module register itself to iommu-omap, make the iommu-omap retrieve the omap-iommu2 operations structure directly when probing the IOMMU device. This ensures that a probed IOMMU will always have valid arch-specific operations. As the arch-specific operations pointer is now initialized at probe time, this change requires turning it from a global variable into a per-device variable. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/iommu/omap-iommu-debug.c | 6 ++- drivers/iommu/omap-iommu.c | 94 +-- drivers/iommu/omap-iommu.h | 10 - drivers/iommu/omap-iommu2.c | 18 +--- 4 files changed, 45 insertions(+), 83 deletions(-) -- Regards, Laurent Pinchart -- 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] clk: add gpio gated clock
Quoting Jyri Sarha (2014-09-05 05:21:34)
The added gpio-gate-clock is a basic clock that can be enabled and
disabled trough a gpio output. The DT binding document for the clock
is also added. For EPROBE_DEFER handling the registering of the clock
has to be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
This is my final attempt to get this generic gpio controlled basic
clock into mainline. Of course I gladly fix any issues that the patch
may have. However, if there is no response, I give up and move it to TI
specific clocks.
I searched through my archives and found a post from January. You Cc'd
me as mturque...@linaro.org. Note that the address is wrapped in
chevrons but there is no name string (e.g. Mike Turquette).
My mailer doesn't parse this well it was not flagged as to:me in my
filters. Maybe other mailers handle this better? If you leave out the
name string in the future then it would probably be best to drop the
chevrons.
I've been sending this patch as a part of Beaglebone-Black HDMI audio
patch series since last autumn. Since the previous version I have done
some minor cleanups and changed the clock's compatible property from
gpio-clock to gpio-gate-clock. All the file names, comments,
etc. have also been changed accordingly.
Is your platform the only one to take advantage of this clock type so
far? I feel that it is esoteric enough that it shouldn't be made
generic.
The main reason is that all of the generic clock types needs to be
overhauled at some point. E.g. the clk-gate should have its
machine-specific logic separated from its machine-independent logic. If
the gate clock were to populate .enable and .disable callbacks and then
leave the actual register banging, or regmap'ing, or gpio'ing up to your
backend driver then that would be a big improvement and would avoid the
need to create this new clock type outright.
So that's on my todo list, but it's not done yet. For your patch I think
that putting this code into drivers/clk/ti would probably be best,
unless other folks could use it as-is. Even if others could use it today
I would want to remove it eventually for the reasons stated in the
paragraph above.
Regards,
Mike
Best regards,
Jyri
.../devicetree/bindings/clock/gpio-gate-clock.txt | 21 ++
drivers/clk/Makefile |1 +
drivers/clk/clk-gpio-gate.c| 204
include/linux/clk-provider.h | 22 +++
4 files changed, 248 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
create mode 100644 drivers/clk/clk-gpio-gate.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
b/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
new file mode 100644
index 000..d3379ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio gated clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be gpio-gate-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = gpio-gate-clock;
+ clocks = parentclk;
+ #clock-cells = 0;
+ enable-gpios = gpio 1 GPIO_ACTIVE_HIGH;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..5d78710 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
obj-$(CONFIG_COMMON_CLK) += clk-fractional-divider.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio-gate.o
ifeq ($(CONFIG_OF), y)
obj-$(CONFIG_COMMON_CLK) += clk-conf.o
endif
diff --git a/drivers/clk/clk-gpio-gate.c b/drivers/clk/clk-gpio-gate.c
new file mode 100644
index 000..9dde885
--- /dev/null
+++ b/drivers/clk/clk-gpio-gate.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2013 - 2014 Texas Instruments Incorporated -
http://www.ti.com
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * 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.
+ *
+ * Gpio gated clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/err.h
+#include linux/device.h
+
+/**
+ * DOC: basic gpio gated clock which can be enabled and disabled
+ * with gpio output
Re: [PATCH 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
Hi Laurent, On Tuesday 09 September 2014 16:33:11 Suman Anna wrote: On 09/09/2014 10:45 AM, Laurent Pinchart wrote: The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants by splitting the driver into a core module and a thin arch-specific operations module. (In practice only the OMAP2+ module omap-iommu2 is implemented, but let's not denigrate the effort.) Thank you for the patch. I had something similar in my list of cleanup TODO items on the OMAP IOMMU driver, but I was intending to cut down more and consolidate the omap-iommu.c and omap-iommu2.c files into a single one. This had been the case from the introduction of the driver going back to v2.6.30, and OMAP1 was never added and I doubt it would be added anytime in the foreseeable future. The arch-specific operations module registers itself with the OMAP IOMMU core module at initialization time. This initializes a module global arch-specific operations pointer, used at runtime by the IOMMU instances. This scheme causes several issues. In addition to making it impossible to support different OMAP IOMMU types in a single system (which in all fairness is quite unlikely to happen), Yep, except for a few enhancements (like reporting Fault PC address on OMAP4 DSPs, and dropping both endianness support), the core IOMMU functionality hasn't changed much between OMAP2 and the latest OMAP4+ SoCs. So, my plan was to completely get rid of the iommu_functions (it also eliminates the need for exporting most of the OMAP IOMMU API). So while I am ok with the current patch, I prefer consolidation than keeping the scalability alive, it can always be added if a need for that arises. What do you think? I agree with your approach, but in the meantime we have a problem to solve. How about applying this patch now (it goes in the right direction anyway), and then removing the iommu functions when you will have time ? Can you give the subsys_initcall solution a try to see if that resolves the problem at hand? That would be a much smaller change, if that doesn't work we can go with this patch. I will work on my cleanup list for 3.19. regards Suman it also causes initialization ordering issues by requiring the arch-specific operations module to be loaded before any IOMMU user. This results in a probe breakage with the OMAP3 ISP driver when not compiled as a module. This can be fixed if we make the current omap-iommu2.c as a subsys_initcall as well, right? regards Suman Fix the problem by inverting the dependency. Instead of having the omap-iommu2 module register itself to iommu-omap, make the iommu-omap retrieve the omap-iommu2 operations structure directly when probing the IOMMU device. This ensures that a probed IOMMU will always have valid arch-specific operations. As the arch-specific operations pointer is now initialized at probe time, this change requires turning it from a global variable into a per-device variable. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/iommu/omap-iommu-debug.c | 6 ++- drivers/iommu/omap-iommu.c | 94 +-- drivers/iommu/omap-iommu.h | 10 - drivers/iommu/omap-iommu2.c | 18 +--- 4 files changed, 45 insertions(+), 83 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5+: Reuse OMAP4 PM code for OMAP5 and DRA7
* Nishanth Menon n...@ti.com [140909 17:16]: OMAP4, OMAP5 and DRA7 share a lot of common logic and data structures. These have been enabled in the previous patches, however, this also means that OMAP5 or DRA7 only builds also need to build OMAP4 logic. Update to reuse OMAP4 logic. This fixes the 'undefined reference to 'omap4_pm_init_early'' in OMAP5 or DRA7 only builds. Fixes: 6af16a1dac5465c (ARM: DRA7: Add hook in SoC initcalls to enable pm initialization) Fixes: 628ed4717000789 (ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization) Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- This fixes the regression with randconfig that Tony reported with omap-for-v3.18/soc branch. Tested with CONFIG_ARCH_OMAP2, CONFIG_ARCH_OMAP3, CONFIG_ARCH_OMAP4, CONFIG_SOC_OMAP5, CONFIG_SOC_AM33XX, CONFIG_SOC_AM43XX, CONFIG_SOC_DRA7XX only builds. Thanks applying into omap-for-v3.18/soc. Tony arch/arm/mach-omap2/Makefile | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 69bbcba..d9dd99c 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -87,9 +87,10 @@ ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o -obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o -obj-$(CONFIG_SOC_DRA7XX) += omap-mpuss-lowpower.o +omap-4-5-pm-common = pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common) +obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-pm-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-pm-common) obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o @@ -102,7 +103,10 @@ endif ifeq ($(CONFIG_CPU_IDLE),y) obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o -obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o +omap-4-5-idle-common = cpuidle44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-idle-common) +obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-idle-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-idle-common) endif # PRCM -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: dts: OMAP5 / DRA7: pinctrl updates
* Nishanth Menon n...@ti.com [140909 14:00]: Hi Tony, Please pull this series was posted[1] and based on the previous pulls [2] [3], updating the dts to enable the relevant feature. NOTE: I have dropped patch #1 of the series based on [4]. These could go to your branch omap-for-v3.18/dt The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-dt-pinctrl-updates for you to fetch changes up to 66b0436977e2c62388d48836ff784f1fedb49c4f: ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable (2014-09-09 08:33:29 -0500) Thanks pulling into omap-for-v3.18/dt. Tony Nishanth Menon (5): ARM: dts: OMAP5: switch to compatible pinctrl ARM: dts: DRA7: switch to compatible pinctrl ARM: dts: AM437x: switch to compatible pinctrl ARM: dts: OMAP5 / DRA7: switch over to interrupts-extended property for UART ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable arch/arm/boot/dts/am4372.dtsi |4 +++- arch/arm/boot/dts/dra7-evm.dts |2 ++ arch/arm/boot/dts/dra7.dtsi| 24 +--- arch/arm/boot/dts/omap5.dtsi | 20 4 files changed, 30 insertions(+), 20 deletions(-) [1] http://marc.info/?l=linux-kernelm=140871681606779w=2 [2] http://marc.info/?l=linux-kernelm=141019565513129w=2 [3] http://marc.info/?l=linux-kernelm=141019566913133w=2 [4] http://marc.info/?l=linux-omapm=141022429924564w=2 Regards, Nishanth Menon -- 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
