[PATCH 2/5] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
From: Hebbar, Gururaja gururaja.heb...@ti.com
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 1 +
arch/arm/plat-omap/include/plat/mmc.h | 1 +
drivers/mmc/host/omap_hsmmc.c | 30 +-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 06d2e03..c277da4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -90,6 +91,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -495,6 +497,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -502,7 +505,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -513,6 +517,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
+*/
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing != MMC_TIMING_UHS_DDR50)
+ ((OMAP_HSMMC_READ(host-base, CAPA) HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host-base, HCTL);
+ if (clkdiv (clk_get_rate(host-fclk)/clkdiv) 2500)
+ regval |= HSPE;
+ else
+ regval = ~HSPE;
+
+ OMAP_HSMMC_WRITE(host-base, HCTL, regval);
+ }
+
[PATCH 3/5] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete
From: Felipe Balbi ba...@ti.com
prepare() is supposed to prevent new children from
being registered. On the MMC subsystem, children
(new cards) registration starts with the card
detect IRQ.
Move card detect IRQ disabling to prepare() so that
no new cards will be registered while we're trying
to suspend.
Likewise, move card detect IRQ enabling to complete()
so we only try to register new children after our MMC
IP is back up.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 44 +++
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c277da4..e91e85a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2065,6 +2065,25 @@ static int __devexit omap_hsmmc_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_PM
+static int omap_hsmmc_prepare(struct device *dev)
+{
+ struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+
+ if (host-pdata-suspend)
+ return host-pdata-suspend(dev, host-slot_id);
+
+ return 0;
+}
+
+static void omap_hsmmc_complete(struct device *dev)
+{
+ struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+
+ if (host-pdata-resume)
+ host-pdata-resume(dev, host-slot_id);
+
+}
+
static int omap_hsmmc_suspend(struct device *dev)
{
int ret = 0;
@@ -2078,23 +2097,10 @@ static int omap_hsmmc_suspend(struct device *dev)
pm_runtime_get_sync(host-dev);
host-suspended = 1;
- if (host-pdata-suspend) {
- ret = host-pdata-suspend(dev, host-slot_id);
- if (ret) {
- dev_dbg(dev, Unable to handle MMC board
-level suspend\n);
- host-suspended = 0;
- return ret;
- }
- }
ret = mmc_suspend_host(host-mmc);
if (ret) {
host-suspended = 0;
- if (host-pdata-resume) {
- if (host-pdata-resume(dev, host-slot_id))
- dev_dbg(dev, Unmask interrupt failed\n);
- }
goto err;
}
@@ -2131,12 +2137,6 @@ static int omap_hsmmc_resume(struct device *dev)
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER))
omap_hsmmc_conf_bus_power(host);
- if (host-pdata-resume) {
- ret = host-pdata-resume(dev, host-slot_id);
- if (ret)
- dev_dbg(dev, Unmask interrupt failed\n);
- }
-
omap_hsmmc_protect_card(host);
/* Notify the core to resume the host */
@@ -2152,8 +2152,10 @@ static int omap_hsmmc_resume(struct device *dev)
}
#else
+#define omap_hsmmc_prepare NULL
+#define omap_hsmmc_completeNULL
#define omap_hsmmc_suspend NULL
-#define omap_hsmmc_resume NULL
+#define omap_hsmmc_resume NULL
#endif
static int omap_hsmmc_runtime_suspend(struct device *dev)
@@ -2181,6 +2183,8 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
+ .prepare= omap_hsmmc_prepare,
+ .complete = omap_hsmmc_complete,
.runtime_suspend = omap_hsmmc_runtime_suspend,
.runtime_resume = omap_hsmmc_runtime_resume,
};
--
1.8.0
--
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 4/5] mmc: omap_hsmmc: cleanup the bitmap definitions of Interrupt Register
Define the most frequently used bitmasks of the Interrupt Enable /
Interrupt Status register with consistent naming ( with _EN suffix).
Use meaningful concatenation of bitfields for INT_EN_MASK, which shows
which interrupts are enabled by default.
No functional changes.
Signed-off-by: Venkatraman S svenk...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 54 +--
1 file changed, 31 insertions(+), 23 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e91e85a..d16ef0f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -80,29 +80,17 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
-#define INT_EN_MASK0x307F0033
-#define BWR_ENABLE (1 4)
-#define BRR_ENABLE (1 5)
-#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
-#define DMA_EN 0x1
+#define DMAE 0x1
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
-#define CC 0x1
-#define TC 0x02
#define OD 0x1
-#define ERR(1 15)
-#define CMD_TIMEOUT(1 16)
-#define DATA_TIMEOUT (1 20)
-#define CMD_CRC(1 17)
-#define DATA_CRC (1 21)
-#define CARD_ERR (1 28)
#define STAT_CLEAR 0x
#define INIT_STREAM_CMD0x
#define DUAL_VOLT_OCR_BIT 7
@@ -111,6 +99,26 @@
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
+/* Interrupt masks for IE and ISE register */
+#define CC_EN (1 0)
+#define TC_EN (1 1)
+#define BWR_EN (1 4)
+#define BRR_EN (1 5)
+#define ERR_EN (1 15)
+#define CTO_EN (1 16)
+#define CCRC_EN(1 17)
+#define CEB_EN (1 18)
+#define CIE_EN (1 19)
+#define DTO_EN (1 20)
+#define DCRC_EN(1 21)
+#define DEB_EN (1 22)
+#define CERR_EN(1 28)
+#define BADA_EN(1 29)
+
+#define INT_EN_MASK(BADA_EN | CERR_EN | DEB_EN | DCRC_EN |\
+ DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | ERR_EN |\
+ BRR_EN | BWR_EN | TC_EN | CC_EN)
+
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MIN_CLOCK 40
@@ -458,13 +466,13 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
unsigned int irq_mask;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE);
+ irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
else
irq_mask = INT_EN_MASK;
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
- irq_mask = ~DTO_ENABLE;
+ irq_mask = ~DTO_EN;
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
@@ -702,8 +710,8 @@ static void send_init_stream(struct omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host-base, CMD, INIT_STREAM_CMD);
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((reg != CC) time_before(jiffies, timeout))
- reg = OMAP_HSMMC_READ(host-base, STAT) CC;
+ while ((reg != CC_EN) time_before(jiffies, timeout))
+ reg = OMAP_HSMMC_READ(host-base, STAT) CC_EN;
OMAP_HSMMC_WRITE(host-base, CON,
OMAP_HSMMC_READ(host-base, CON) ~INIT_STREAM);
@@ -794,7 +802,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
}
if (host-use_dma)
- cmdreg |= DMA_EN;
+ cmdreg |= DMAE;
host-req_in_progress = 1;
@@ -1014,11 +1022,11 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
data = host-data;
dev_vdbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
- if (status ERR) {
+ if (status ERR_EN) {
omap_hsmmc_dbg_report_irq(host, status);
- if (status (CMD_TIMEOUT | DATA_TIMEOUT))
+ if (status (CTO_EN | DTO_EN))
hsmmc_command_incomplete(host, -ETIMEDOUT);
- else if (status (CMD_CRC | DATA_CRC))
+ else if (status (CCRC_EN | DCRC_EN))
hsmmc_command_incomplete(host, -EILSEQ);
if (host-cmd)
@@ -1029,9
[PATCH 5/5] mmc: omap_hsmmc: convert critical failure reports to dev_err
Fatal errors for the driver are not reported when just error
debug is enabled. Convert selected dev_dbg to dev_err for
accurate error reporting.
Reported-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d16ef0f..830c59b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -313,7 +313,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
- dev_dbg(host-dev, vmmc regulator missing\n);
+ dev_err(host-dev, vmmc regulator missing\n);
return PTR_ERR(reg);
} else {
mmc_slot(host).set_power = omap_hsmmc_set_power;
@@ -1136,7 +1136,7 @@ static int omap_hsmmc_switch_opcond(struct
omap_hsmmc_host *host, int vdd)
return 0;
err:
- dev_dbg(mmc_dev(host-mmc), Unable to switch operating voltage\n);
+ dev_err(mmc_dev(host-mmc), Unable to switch operating voltage\n);
return ret;
}
@@ -1395,7 +1395,7 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host *host,
struct mmc_request *req)
if (host-use_dma) {
ret = omap_hsmmc_start_dma_transfer(host, req);
if (ret != 0) {
- dev_dbg(mmc_dev(host-mmc), MMC start dma failure\n);
+ dev_err(mmc_dev(host-mmc), MMC start dma failure\n);
return ret;
}
}
@@ -1930,13 +1930,13 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
ret = request_irq(host-irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
- dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
+ dev_err(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
goto err_irq;
}
if (pdata-init != NULL) {
if (pdata-init(pdev-dev) != 0) {
- dev_dbg(mmc_dev(host-mmc),
+ dev_err(mmc_dev(host-mmc),
Unable to configure MMC IRQs\n);
goto err_irq_cd_init;
}
@@ -1959,7 +1959,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
mmc_hostname(mmc), host);
if (ret) {
- dev_dbg(mmc_dev(host-mmc),
+ dev_err(mmc_dev(host-mmc),
Unable to grab MMC CD IRQ\n);
goto err_irq_cd;
}
--
1.8.0
--
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/4] rtc: OMAP: Add system pm_power_off to rtc driver
Hi Anil,
On 11/06/2012 06:07 AM, AnilKumar, Chimata wrote:
On Mon, Nov 05, 2012 at 22:13:25, Cousson, Benoit wrote:
Hi Anil / Colin,
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Added while (1); after the above steps to make sure that no other
process acquire cpu. Otherwise we might see an unexpected behaviour
because we are shutting down all the power rails of SoC except RTC.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 79
+++-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
I don't know how it is connected at board level, but I'm not sure the
binding is the proper one.
Hi Benoit,
| __ ___ |
| | || | |
| |RTC || | |
| |PMIC | Line | | |
| |PWR_EN|===|PWR_EN | |
| |__||___| |
| AM335x SoC TPS65217 |
||
||
BeagleBone
This is how RTC PMIC_PWR_EN is connected to PWR_EN of TPS65217 PMIC. Only when
RTC pull low in PMIC_PWR_EN then PMIC will go to power off state provided
TPS65217
status should be changed to STATUS_OFF.
ALARM2 event should be trigger to configure PMIC_PWR_EN properly then the
Line
driven low so that PMIC will go to shutdown mode.
Thanks for the nice diagram :-)
I'm wondering if we cannot abuse the gpio binding to describe that
connection instead of creating two custom attributes (PMIC + RTC).
Ideally we should do that without having to change the RTC to use the
gpiolib at all.
rtc: rtc@44e3e000 {
compatible = ti,da830-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75, 76;
ti,hwmods = rtc;
/* expose the PWR_EN functionality of this RTC*/
gpio-controller;
#gpio-cells = 0; /* assuming we can use 0 ??? */
};
...
tps: tps@24 {
compatible = ti,tps65217;
/*
* Enable the power enable feature from
* the input line if that attribute is there.
*/
gpio-power-en = rtc; /* PWR_EN */
...
}
Any thought?
Regards,
Benoit
--
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] usb: musb: dsps: dt binding - add resources, example
On 11/06/2012 05:44 PM, Felipe Balbi wrote:
Hi,
On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote:
OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.
Signed-off-by: Afzal Mohammed af...@ti.com
this looks fine to me:
Reviewed-by: Felipe Balbi ba...@ti.com
Benoit, do you take Documentation patches too ?
Well, ideally it should go with the driver change. But if this is a
simple change related to generic attribute I can take it.
Regards,
Benoit
---
v2: node name changed to usb
.../devicetree/bindings/usb/am33xx-usb.txt | 21
+
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..ea840f7 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
AM33XX MUSB GLUE
- compatible : Should be ti,musb-am33xx
+ - reg : offset and length of register sets, first usbss, then for musb
instances
+ - interrupts : usbss, musb instance interrupts in order
- ti,hwmods : must be usb_otg_hs
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+Example:
+
+usb@4740 {
+compatible = ti,musb-am33xx;
+reg = 0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800; /* musb instance 1 */
+interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+multipoint = 1;
+num-eps = 16;
+ram-bits = 12;
+port0-mode = 3;
+port1-mode = 3;
+power = 250;
+ti,hwmods = usb_otg_hs;
+};
--
1.7.12
--
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 gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
On 11/06/2012 10:44 AM, Matthieu CASTET wrote:
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
I think you need to have something in the changelog for the patch
describing why this change is needed and what device this has been
tested on.
---
arch/arm/mach-omap2/gpmc.c |7 ++-
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..3957ffc 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -333,8 +333,13 @@ int gpmc_cs_set_timings(int cs, const struct
gpmc_timings *t)
if (gpmc_capability GPMC_HAS_WR_DATA_MUX_BUS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
- if (gpmc_capability GPMC_HAS_WR_ACCESS)
+ if (gpmc_capability GPMC_HAS_WR_ACCESS) {
+ /* XXX check on which hardware it is supported */
I understand that you may not have all the documentation but lets fix
this now.
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, busturnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycledelay);
Looking at the documentation for OMAP2420, OMAP3430, OMAP4430 and
OMAP5430, the above fields are present and same size location for all
OMAP devices. So this does not need to be done under the HAS_WR_ACCESS
field test. In fact, I believe that Afzal was going to add these fields
in a patch and was doing it for all devices [1].
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..34ca454 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,8 @@ struct gpmc_timings {
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
+ u16 cycle2cycledelay; /* CYCLE2CYCLEDELAY */
+ u16 busturnaround; /* BUSTURNAROUND */
So you should be able to move these out of OMAP3430 specific as they are
generic.
Cheers
Jon
[1] http://marc.info/?l=linux-omapm=134037095705900w=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 V4 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
This patch-series adds support for, [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/7]: Add hwmod entry for MDIO module, required for MDIO driver. [4/7]: cpsw: simplify the setup of the register pointers [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file [6/7]: Enable CPSW support to omap2plus_defconfig [7/7]: cpsw: Kernel warn fix during suspend This patch series has been created on top of net-next/master and tested on BeagleBone platform for NFS boot and basic ping test cases. Changes from V3: * Removed unnecessary flags in Davinci MDIO Hwmod entry. Mugunthan V N (4): ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support net: cpsw: halt network stack before halting the device during suspend Richard Cochran (1): cpsw: simplify the setup of the register pointers Vaibhav Hiremath (2): net: davinci_mdio: Fix typo mistake in calling runtime-pm api net: cpsw: Add parent-child relation support between cpsw and mdio Documentation/devicetree/bindings/net/cpsw.txt | 34 arch/arm/boot/dts/am335x-bone.dts |8 + arch/arm/boot/dts/am335x-evm.dts |8 + arch/arm/boot/dts/am33xx.dtsi | 42 + arch/arm/configs/omap2plus_defconfig |3 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 31 drivers/net/ethernet/ti/cpsw.c | 231 ++-- drivers/net/ethernet/ti/davinci_mdio.c |2 +- include/linux/platform_data/cpsw.h | 19 -- 9 files changed, 192 insertions(+), 186 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
[PATCH V4 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
This patch adds hwmod entry for davinci MDIO module,
creating parent-child relationship between CPSW and MDIO module.
This Parent-child relation is required in order to use common resources
like, clock, but still maintaining the logical separation between them.
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci
family of devices, so separate and independent platform devices
drivers for CPSW and MDIO is implemented.
In case of AM33XX, the resources are shared and common register
bit-field is provided to control module/clock enable/disable,
makes it difficult to handle common resources from both drivers.
So the solution is, create parent-child relationship between
CPGMAC MDIO modules.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
Acked-by: Richard Cochran richardcoch...@gmail.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 31
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..3125835 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -674,6 +674,7 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
.name = cpgmac0,
.class = am33xx_cpgmac0_hwmod_class,
.clkdm_name = cpsw_125mhz_clkdm,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
.mpu_irqs = am33xx_cpgmac0_irqs,
.main_clk = cpsw_125mhz_gclk,
.prcm = {
@@ -685,6 +686,20 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
};
/*
+ * mdio class
+ */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+ .name = davinci_mdio,
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+ .name = davinci_mdio,
+ .class = am33xx_mdio_hwmod_class,
+ .clkdm_name = cpsw_125mhz_clkdm,
+ .main_clk = cpsw_125mhz_gclk,
+};
+
+/*
* dcan class
*/
static struct omap_hwmod_class am33xx_dcan_hwmod_class = {
@@ -2501,6 +2516,21 @@ static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x4808,
@@ -3371,6 +3401,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_l3_main__tptc2,
am33xx_l3_s__usbss,
am33xx_l4_hs__cpgmac0,
+ am33xx_cpgmac0__mdio,
NULL,
};
--
1.7.0.4
--
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 V4 7/7] net: cpsw: halt network stack before halting the device during suspend
Move network stack halt APIs before halting the hardware to ensure no packets are queued to hardware during closing the device during suspend sequence. Signed-off-by: Mugunthan V N mugunthan...@ti.com Acked-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/cpsw.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index f94aa8f..b46dbb4 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -698,12 +698,12 @@ static int cpsw_ndo_stop(struct net_device *ndev) struct cpsw_priv *priv = netdev_priv(ndev); cpsw_info(priv, ifdown, shutting down cpsw device\n); - cpsw_intr_disable(priv); - cpdma_ctlr_int_ctrl(priv-dma, false); - cpdma_ctlr_stop(priv-dma); netif_stop_queue(priv-ndev); napi_disable(priv-napi); netif_carrier_off(priv-ndev); + cpsw_intr_disable(priv); + cpdma_ctlr_int_ctrl(priv-dma, false); + cpdma_ctlr_stop(priv-dma); cpsw_ale_stop(priv-ale); for_each_slave(priv, cpsw_slave_stop, priv); pm_runtime_put_sync(priv-pdev-dev); -- 1.7.0.4 -- 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 V4 4/7] cpsw: simplify the setup of the register pointers
From: Richard Cochran richardcoch...@gmail.com
Instead of having a host of different register offsets in the device tree,
this patch simplifies the CPSW code by letting the driver set the proper
register offsets automatically, based on the CPSW version.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 34
drivers/net/ethernet/ti/cpsw.c | 209 +--
include/linux/platform_data/cpsw.h | 19 --
3 files changed, 82 insertions(+), 180 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 2214607..6cf5d92 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -9,15 +9,7 @@ Required properties:
number
- interrupt-parent : The parent interrupt controller
- cpdma_channels : Specifies number of channels in CPDMA
-- host_port_no : Specifies host port shift
-- cpdma_reg_ofs: Specifies CPDMA submodule register offset
-- cpdma_sram_ofs : Specifies CPDMA SRAM offset
-- ale_reg_ofs : Specifies ALE submodule register offset
- ale_entries : Specifies No of entries ALE can hold
-- host_port_reg_ofs: Specifies host port register offset
-- hw_stats_reg_ofs : Specifies hardware statistics register offset
-- cpts_reg_ofs : Specifies the offset of the CPTS registers
-- bd_ram_ofs : Specifies internal desciptor RAM offset
- bd_ram_size : Specifies internal descriptor RAM size
- rx_descs : Specifies number of Rx descriptors
- mac_control : Specifies Default MAC control register content
@@ -26,8 +18,6 @@ Required properties:
- cpts_active_slave: Specifies the slave to use for time stamping
- cpts_clock_mult : Numerator to convert input clock ticks into
nanoseconds
- cpts_clock_shift : Denominator to convert input clock ticks into
nanoseconds
-- slave_reg_ofs: Specifies slave register offset
-- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
@@ -49,15 +39,7 @@ Examples:
interrupts = 55 0x4;
interrupt-parent = intc;
cpdma_channels = 8;
- host_port_no = 0;
- cpdma_reg_ofs = 0x800;
- cpdma_sram_ofs = 0xa00;
- ale_reg_ofs = 0xd00;
ale_entries = 1024;
- host_port_reg_ofs = 0x108;
- hw_stats_reg_ofs = 0x900;
- cpts_reg_ofs = 0xc00;
- bd_ram_ofs = 0x2000;
bd_ram_size = 0x2000;
no_bd_ram = 0;
rx_descs = 64;
@@ -67,15 +49,11 @@ Examples:
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
- slave_reg_ofs = 0x200;
- sliver_reg_ofs = 0xd80;
phy_id = davinci_mdio.16:00;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = 0x300;
- sliver_reg_ofs = 0xdc0;
phy_id = davinci_mdio.16:01;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
@@ -87,15 +65,7 @@ Examples:
compatible = ti,cpsw;
ti,hwmods = cpgmac0;
cpdma_channels = 8;
- host_port_no = 0;
- cpdma_reg_ofs = 0x800;
- cpdma_sram_ofs = 0xa00;
- ale_reg_ofs = 0xd00;
ale_entries = 1024;
- host_port_reg_ofs = 0x108;
- hw_stats_reg_ofs = 0x900;
- cpts_reg_ofs = 0xc00;
- bd_ram_ofs = 0x2000;
bd_ram_size = 0x2000;
no_bd_ram = 0;
rx_descs = 64;
@@ -105,15 +75,11 @@ Examples:
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
- slave_reg_ofs = 0x200;
- sliver_reg_ofs = 0xd80;
phy_id = davinci_mdio.16:00;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = 0x300;
- sliver_reg_ofs = 0xdc0;
phy_id = davinci_mdio.16:01;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
diff --git
[PATCH V4 5/7] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
Acked-by: Richard Cochran richardcoch...@gmail.com
---
arch/arm/boot/dts/am335x-bone.dts |8 +++
arch/arm/boot/dts/am335x-evm.dts |8 +++
arch/arm/boot/dts/am33xx.dtsi | 42 +
3 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..2a0c8fe 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,47 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ mac: ethernet@4A10 {
+ compatible = ti,cpsw;
+ ti,hwmods = cpgmac0;
+ cpdma_channels = 8;
+ ale_entries = 1024;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
+ slaves = 2;
+ cpts_active_slave = 0;
+ cpts_clock_mult = 0x8000;
+ cpts_clock_shift = 29;
+ reg = 0x4a10 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = intc;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend
c0_misc_pend*/
+ interrupts = 40 41 42 43;
+ ranges;
+ cpsw_emac0: slave@0 {
+ phy_id = davinci_mdio.16:00;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+ cpsw_emac1: slave@1 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: mdio@4a101000 {
+ compatible = ti,davinci_mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = davinci_mdio;
+ bus_freq = 100;
+ reg = 0x4a101000 0x100;
+ };
+ };
};
};
--
1.7.0.4
--
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 V4 1/7] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
From: Vaibhav Hiremath hvaib...@ti.com By mistake (most likely a copy-paste), instead of pm_runtime_get_sync() api, driver is calling pm_runtime_put_sync() api in resume callback function. The bug was introduced by commit id (ae2c07aaf74: davinci_mdio: runtime PM support). Now, the reason why it didn't impact functionality is, the patch has been tested on AM335x-EVM and BeagleBone platform while submitting; and in case of AM335x the MDIO driver doesn't control the module enable/disable part, which is handled by CPSW driver. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Mugunthan V N mugunthan...@ti.com Acked-by: Peter Korsgaard jac...@sunsite.dk Acked-by: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/davinci_mdio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c index 51a96db..ae74280 100644 --- a/drivers/net/ethernet/ti/davinci_mdio.c +++ b/drivers/net/ethernet/ti/davinci_mdio.c @@ -465,7 +465,7 @@ static int davinci_mdio_resume(struct device *dev) u32 ctrl; spin_lock(data-lock); - pm_runtime_put_sync(data-dev); + pm_runtime_get_sync(data-dev); /* restart the scan state machine */ ctrl = __raw_readl(data-regs-control); -- 1.7.0.4 -- 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 V4 6/7] ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
Enable CPSW support in defconfig which is present in AM33xx SoC Signed-off-by: Mugunthan V N mugunthan...@ti.com Acked-by: Richard Cochran richardcoch...@gmail.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a4b330e..41b595e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -242,3 +242,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_TI_DAVINCI_MDIO=y +CONFIG_TI_DAVINCI_CPDMA=y +CONFIG_TI_CPSW=y -- 1.7.0.4 -- 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 V4 2/7] net: cpsw: Add parent-child relation support between cpsw and mdio
From: Vaibhav Hiremath hvaib...@ti.com
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci family
of devices. Now based on requirement, use-case and available technology
nodes the integration of these sub-modules varies across devices.
So coming back to Linux net driver, currently separate and independent
platform devices drivers for CPSW and MDIO is implemented. In case of
Davinci they both has separate control, from resources perspective,
like clock.
In case of AM33XX, the resources are shared and only one register
bit-field is provided to control module/clock enable/disable, makes it
difficult to handle common resource.
So the solution here implemented in this patch is,
Create parent-child relationship between both the drivers, making
CPSW as a parent and MDIO as its child and enumerate all the child nodes
under CPSW module.
Both the drivers will function exactly the way it was operating before,
including runtime-pm functionality. No change is required in MDIO driver
(for that matter to any child driver).
As this is only supported during DT boot, the parent-child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making MDIO as a child to CPSW node.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
Acked-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7654a62..7007aba 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1144,7 +1144,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data-mac_control = prop;
- for_each_child_of_node(node, slave_node) {
+ for_each_node_by_name(slave_node, slave) {
struct cpsw_slave_data *slave_data = data-slave_data + i;
const char *phy_id = NULL;
const void *mac_addr = NULL;
@@ -1179,6 +1179,14 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
i++;
}
+ /*
+* Populate all the child nodes here...
+*/
+ ret = of_platform_populate(node, NULL, NULL, pdev-dev);
+ /* We do not want to force this, as in some cases may not have child */
+ if (ret)
+ pr_warn(Doesn't have any child node\n);
+
return 0;
error_ret:
@@ -1212,6 +1220,11 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
priv-msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
priv-rx_packet_max = max(rx_packet_max, 128);
+ /*
+* This may be required here for child devices.
+*/
+ pm_runtime_enable(pdev-dev);
+
if (cpsw_probe_dt(priv-data, pdev)) {
pr_err(cpsw: platform data missing\n);
ret = -ENODEV;
@@ -1238,7 +1251,6 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
for (i = 0; i data-slaves; i++)
priv-slaves[i].slave_num = i;
- pm_runtime_enable(pdev-dev);
priv-clk = clk_get(pdev-dev, fck);
if (IS_ERR(priv-clk)) {
dev_err(pdev-dev, fck is not found\n);
--
1.7.0.4
--
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 3/3] omap prcm cleanup for v3.8 merge window, part1
* Olof Johansson o...@lixom.net [121105 10:53]: The history of this branch looks a little odd. Did you mean to merge in cleanup-headers on top of Paul's branch in it? It seems to add no value -- all that code is already in our branch and it resolves no conflicts, etc. Oh that was because I wanted to keep the header clean up separate and Paul needed some base for further PRCM work that would not conflict with the header changes. And I wanted to get the first set of Paul's changes into linux next early to avoid a big pile of pull requests later on. That being said, it causes no harm, and I've pulled it in as is. OK thanks. 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 1/3] omap gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
Jon Hunter a écrit :
On 11/06/2012 10:44 AM, Matthieu CASTET wrote:
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..34ca454 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,8 @@ struct gpmc_timings {
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
+u16 cycle2cycledelay; /* CYCLE2CYCLEDELAY */
+u16 busturnaround; /* BUSTURNAROUND */
So you should be able to move these out of OMAP3430 specific as they are
generic.
Thanks for the quick review.
I will post another patch, unless this is already done in Afzal patch (Is there
a tree where I can get Afzal pending patches ?)
Matthieu
--
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/4] i2c: introduce i2c-cbus driver
* Aaro Koskinen aaro.koski...@iki.fi [121031 11:10]:
Add i2c driver to enable access to devices behind CBUS on Nokia Internet
Tablets.
The patch also adds CBUS I2C configuration for N8x0 which is one of the
users of this driver.
Added Wolfram Sang w.s...@pengutronix.de to cc so he
knows to pick this one if no more comments. You may need to
resend with him in cc.
Regards,
Tony
Cc: linux-...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap2/board-n8x0.c | 42 ++
drivers/i2c/busses/Kconfig | 10 ++
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-cbus.c| 300
++
include/linux/i2c-cbus.h | 27
5 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cbus.c
create mode 100644 include/linux/i2c-cbus.h
diff --git a/arch/arm/mach-omap2/board-n8x0.c
b/arch/arm/mach-omap2/board-n8x0.c
index d95f727..7ea0348 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -16,8 +16,10 @@
#include linux/gpio.h
#include linux/init.h
#include linux/io.h
+#include linux/irq.h
#include linux/stddef.h
#include linux/i2c.h
+#include linux/i2c-cbus.h
#include linux/spi/spi.h
#include linux/usb/musb.h
#include linux/platform_data/spi-omap2-mcspi.h
@@ -39,6 +41,45 @@
#define TUSB6010_GPIO_ENABLE 0
#define TUSB6010_DMACHAN 0x3f
+#if defined(CONFIG_I2C_CBUS) || defined(CONFIG_I2C_CBUS_MODULE)
+static struct i2c_cbus_platform_data n8x0_cbus_data = {
+ .clk_gpio = 66,
+ .dat_gpio = 65,
+ .sel_gpio = 64,
+};
+
+static struct platform_device n8x0_cbus_device = {
+ .name = i2c-cbus,
+ .id = 3,
+ .dev= {
+ .platform_data = n8x0_cbus_data,
+ },
+};
+
+static struct i2c_board_info n8x0_i2c_board_info_3[] __initdata = {
+ {
+ I2C_BOARD_INFO(retu-mfd, 0x01),
+ },
+};
+
+static void __init n8x0_cbus_init(void)
+{
+ const int retu_irq_gpio = 108;
+
+ if (gpio_request_one(retu_irq_gpio, GPIOF_IN, Retu IRQ))
+ return;
+ irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ n8x0_i2c_board_info_3[0].irq = gpio_to_irq(retu_irq_gpio);
+ i2c_register_board_info(3, n8x0_i2c_board_info_3,
+ ARRAY_SIZE(n8x0_i2c_board_info_3));
+ platform_device_register(n8x0_cbus_device);
+}
+#else /* CONFIG_I2C_CBUS */
+static void __init n8x0_cbus_init(void)
+{
+}
+#endif /* CONFIG_I2C_CBUS */
+
#if defined(CONFIG_USB_MUSB_TUSB6010) ||
defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
/*
* Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
@@ -677,6 +718,7 @@ static void __init n8x0_init_machine(void)
gpmc_onenand_init(board_onenand_data);
n8x0_mmc_init();
n8x0_usb_init();
+ n8x0_cbus_init();
}
MACHINE_START(NOKIA_N800, Nokia N800)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 65dd599..d01c8ef 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -338,6 +338,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CBUS
+ tristate CBUS I2C driver
+ depends on GENERIC_GPIO
+ help
+ Support for CBUS access using I2C API. Mostly relevant for Nokia
+ Internet Tablets (770, N800 and N810).
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cbus.
+
config I2C_CPM
tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
depends on (CPM1 || CPM2) OF_I2C
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 2d33d62..3c548b1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_I2C_POWERMAC) += i2c-powermac.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CBUS) += i2c-cbus.o
obj-$(CONFIG_I2C_CPM)+= i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI)+= i2c-davinci.o
obj-$(CONFIG_I2C_DESIGNWARE_CORE)+= i2c-designware-core.o
diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
new file mode 100644
index 000..1ea7667
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cbus.c
@@ -0,0 +1,300 @@
+/*
+ * CBUS I2C driver for Nokia Internet Tablets.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall, Mikko Ylinen and
+ * Felipe Balbi. Converted to I2C driver by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main
Re: [PATCH v2 3/4] watchdog: introduce retu_wdt driver
* Aaro Koskinen aaro.koski...@iki.fi [121031 11:10]:
Introduce Retu watchdog driver.
Added Wim Van Sebroeck w...@iguana.be to cc so he knows to
pick up the patches after no more comments. You may need
to resend.
Regards,
Tony
Cc: linux-watch...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/watchdog/Kconfig| 12 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/retu_wdt.c | 178
+++
3 files changed, 191 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/retu_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ad1bb93..c3a836d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,18 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config RETU_WATCHDOG
+ tristate Retu watchdog
+ depends on MFD_RETU
+ select WATCHDOG_CORE
+ help
+ Retu watchdog driver for Nokia Internet Tablets (700, N800,
+ N810). At least on N800 the watchdog cannot be disabled, so
+ this driver is essential and you should enable it.
+
+ To compile this driver as a module, choose M here: the
+ module will be called retu_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 572b39b..d2f1c0c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_STMP3XXX_WATCHDOG) += stmp3xxx_wdt.o
obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/retu_wdt.c b/drivers/watchdog/retu_wdt.c
new file mode 100644
index 000..aeb0f39
--- /dev/null
+++ b/drivers/watchdog/retu_wdt.c
@@ -0,0 +1,178 @@
+/*
+ * Retu watchdog driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Amit Kucheria and Michael Buesch.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+
+/* Watchdog timer values in seconds */
+#define RETU_WDT_MAX_TIMER 63
+
+struct retu_wdt_dev {
+ struct retu_dev *rdev;
+ struct device *dev;
+ struct delayed_work ping_work;
+};
+
+/*
+ * Since Retu watchdog cannot be disabled in hardware, we must kick it
+ * with a timer until userspace watchdog software takes over. If
+ * CONFIG_WATCHDOG_NOWAYOUT is set, we never start the feeding.
+ */
+static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ schedule_delayed_work(wdev-ping_work,
+ round_jiffies_relative(RETU_WDT_MAX_TIMER * HZ / 2));
+}
+
+static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ cancel_delayed_work_sync(wdev-ping_work);
+}
+
+static void retu_wdt_ping_work(struct work_struct *work)
+{
+ struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
+ struct retu_wdt_dev, ping_work);
+ retu_wdt_ping_enable(wdev);
+}
+
+static int retu_wdt_start(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_disable(wdev);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_stop(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_enable(wdev);
+
+ return 0;
+}
+
+static int retu_wdt_ping(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+
Re: [PATCH v2 4/4] input: misc: introduce retu-pwrbutton
* Aaro Koskinen aaro.koski...@iki.fi [121031 11:07]:
Add Retu power button driver.
Added Dmitry Torokhov dmitry.torok...@gmail.com to cc so he knows
to pick this after no more comments. You may need to resend.
Regards,
Tony
Cc: linux-in...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/input/misc/Kconfig | 10 +++
drivers/input/misc/Makefile |1 +
drivers/input/misc/retu-pwrbutton.c | 118
+++
3 files changed, 129 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/retu-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..e5be189 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -367,6 +367,16 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_RETU_PWRBUTTON
+ tristate Retu Power button Driver
+ depends on MFD_RETU
+ help
+ Say Y here if you want to enable power key reporting via the
+ Retu chips found in Nokia Internet Tablets (770, N800, N810).
+
+ To compile this driver as a module, choose M here. The module will
+ be called retu-pwrbutton.
+
config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 83fe6f5..4fbee0d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE)+= powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SPARCSPKR)+= sparcspkr.o
diff --git a/drivers/input/misc/retu-pwrbutton.c
b/drivers/input/misc/retu-pwrbutton.c
new file mode 100644
index 000..51e94a7
--- /dev/null
+++ b/drivers/input/misc/retu-pwrbutton.c
@@ -0,0 +1,118 @@
+/*
+ * Retu power button driver.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Original code written by Ari Saastamoinen, Juha Yrjölä and Felipe Balbi.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/input.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+
+#define RETU_STATUS_PWRONX (1 5)
+
+struct retu_pwrbutton {
+ struct input_dev*idev;
+ struct retu_dev *rdev;
+ struct device *dev;
+ boolpressed;
+ int irq;
+};
+
+static irqreturn_t retu_pwrbutton_irq(int irq, void *_pwr)
+{
+ struct retu_pwrbutton *pwr = _pwr;
+ bool state;
+
+ state = !(retu_read(pwr-rdev, RETU_REG_STATUS) RETU_STATUS_PWRONX);
+
+ if (pwr-pressed != state) {
+ input_report_key(pwr-idev, KEY_POWER, state);
+ input_sync(pwr-idev);
+ pwr-pressed = state;
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit retu_pwrbutton_probe(struct platform_device *pdev)
+{
+ struct retu_dev *rdev = dev_get_drvdata(pdev-dev.parent);
+ struct retu_pwrbutton *pwr;
+ int ret;
+
+ pwr = devm_kzalloc(pdev-dev, sizeof(*pwr), GFP_KERNEL);
+ if (!pwr)
+ return -ENOMEM;
+
+ pwr-rdev = rdev;
+ pwr-dev = pdev-dev;
+ pwr-irq = platform_get_irq(pdev, 0);
+ platform_set_drvdata(pdev, pwr);
+
+ ret = devm_request_threaded_irq(pdev-dev, pwr-irq, NULL,
+ retu_pwrbutton_irq, 0, retu-pwrbutton,
+ pwr);
+ if (ret 0)
+ return ret;
+
+ pwr-idev = input_allocate_device();
+ if (!pwr-idev)
+ return -ENOMEM;
+
+ pwr-idev-evbit[0] = BIT_MASK(EV_KEY);
+ pwr-idev-keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+ pwr-idev-name = retu-pwrbutton;
+
+ ret = input_register_device(pwr-idev);
+ if (ret 0) {
+
Re: [PATCH v2 03/14] ARM: OMAP5: id: Add cpu id for ES versions
* Roger Quadros rog...@ti.com [121102 03:05]: Hi Santosh, I believe the change from cpu_is_xxx() to soc_is_xxx() just for OMAP5 leads to unnecessary confusion, even though soc_is_ is more technically correct. All of them will be eventually soc_is_xxx() and private to arch/arm/mach-omap2. 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] usb: musb: dsps: dt binding - add resources, example
Hi, On Tue, Nov 06, 2012 at 05:58:57PM +0100, Benoit Cousson wrote: On 11/06/2012 05:44 PM, Felipe Balbi wrote: Hi, On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote: OMAP2+ family of devices are now obtaining resources via DT, earlier it was obtained from hwmod. Update binding document accrodingly, while at it add example. Signed-off-by: Afzal Mohammed af...@ti.com this looks fine to me: Reviewed-by: Felipe Balbi ba...@ti.com Benoit, do you take Documentation patches too ? Well, ideally it should go with the driver change. But if this is a simple change related to generic attribute I can take it. ok, cool. Please take this via your tree. thanks -- balbi signature.asc Description: Digital signature
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
* Grant Likely grant.lik...@secretlab.ca [121106 03:16]: On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Another can of worms is the pinctrl nodes. Yes... new pinctrl data would need to trigger adding new data to pinctrl. I don't know if the pinctrl api supports that. The actual pins stay the same, just their configuration changes. AFAIK all that is already supported using the pinctrl framework. For example, considering hotplugging capes on the beaglebone: 1. You need to map all the sensible modes for the pins exposed to the capes in the board specific .dts file. This will add roughly 4 x nr_capbus_pins named modes in the .dts file so not too bad. 2. Claim all the capebus pins during the capbus driver probe and set them to some safe mode. 3. Try to detect the connected cape(s) over i2c. 4. Use pinctr_select_state to set the desired modes for the pins used by the cape(s). 5. Enable capebus regulators and clocks etc. 6. Load the driver modules for whatever omap internal devices the cape supports. You could also claim the pin for the omap internal devices instead of claiming them in the capebus, but then things can get messy with binding and unbinding the drivers. So just claiming all the pins in the capebus probably keeps things simpler. 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 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
* Matthieu CASTET matthieu.cas...@parrot.com [121106 08:49]: Igor Grinberg a écrit : Cc: Tony Lindgren, Afzal Mohammed, On 11/06/12 12:51, Matthieu CASTET wrote: This allow to clean the omap nand driver that were trying in x8 and x16 bits mode. This also make work onfi detection on beagleboard : Before : [1.954803] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit), page size: 2048, OOB size: 64 After : [1.914825] ONFI param page 0 valid [1.919158] ONFI flash detected [1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron MT29F2G16ABD), page size: 2048, OOB size: 64 platform data devsize is renamed bussize. It now indicate the maximun size of the nand bus. Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com I think, you should base on one of Tony's branches with that kind of patches. Because, for example the omap_nand_flash_init() function does not exist anymore in Tony's master and may be several more things will need to have adjustments. Also, the GPMC related stuff inside the NAND driver should probably be coordinated with Afzal, as he is reworking the whole GPMC related code. Thanks for the info. Where such tree could be found ? You should be able to use omap-for-v3.8/cleanup-headers-gpmc branch as a base for your patches [1]. Eventually once when we're done with all the clean up, the MTD driver should be completely separated from the core omap code and I'll be out of the way. Regards, Tony [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=shortlog;h=refs/heads/omap-for-v3.8/cleanup-headers-gpmc -- 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: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Felipe Balbi ba...@ti.com [121106 03:40]: Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz min...@mina86.com I need more Acks here. Only got one from Nicolas. Anyone else ? For omaps: Acked-by: Tony Lindgren t...@atomide.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
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Tony Lindgren t...@atomide.com [121106 10:41]: * Felipe Balbi ba...@ti.com [121106 03:40]: Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz min...@mina86.com I need more Acks here. Only got one from Nicolas. Anyone else ? For omaps: Acked-by: Tony Lindgren t...@atomide.com Heh I guess no omap changes there, so probably not worth adding then. 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 3/6] ARM: OMAP: voltage: move voltdm_reset to platform_data header
* Nishanth Menon n...@ti.com [121105 07:04]: Move voltdm_reset to include/linux/platform_data/voltage-omap.h Acked-by: Jean Pihet j-pi...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/voltage.h |1 - include/linux/platform_data/voltage-omap.h |1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index af9d469..0665f21 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -149,5 +149,4 @@ int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void *user), int voltdm_for_each_pwrdm(struct voltagedomain *voltdm, int (*fn)(struct voltagedomain *voltdm, struct powerdomain *pwrdm)); -void voltdm_reset(struct voltagedomain *voltdm); #endif diff --git a/include/linux/platform_data/voltage-omap.h b/include/linux/platform_data/voltage-omap.h index 5be4d5d..4eb3d43 100644 --- a/include/linux/platform_data/voltage-omap.h +++ b/include/linux/platform_data/voltage-omap.h @@ -36,4 +36,5 @@ int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); +void voltdm_reset(struct voltagedomain *voltdm); #endif The include/linux/platform_data/voltage-omap.h should only contain pure platform_data, these should internal defines to the driver. Looks like there are other things there too that's not platform data: struct voltagedomain *voltdm_lookup(const char *name); int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); Can you please add a patch fixing that ASAP? Thanks, 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] [PATCH] remove pcm049 from Makefile
* Sergei Shtylyov sshtyl...@mvista.com [121030 04:49]: Hello. You forgot to sign off on the patch, so it can't be applied. Any news on this? It's also missing the description. 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: [GIT PULL v2] ARM: OMAP: more hwmod/PRCM fixes for 3.7-rc
* Paul Walmsley p...@pwsan.com [121031 19:54]: Hi Tony The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64: Linux 3.7-rc3 (2012-10-28 12:24:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b2-for-3.7-rc for you to fetch changes up to bc05244e65f26b7b6f87e0964bfe277803914ed9: ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init (2012-10-31 05:02:31 -0600) A few more OMAP fixes for the 3.7-rc timeframe. Mostly hwmod fixes. This second revision includes a missing fix from Kevin for a GPIO problem. Thanks pulling into omap-for-v3.7-rc4/fixes. 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: [GIT PULL] ARM: OMAP: PM: few more fixes for v3.7-rc
* Kevin Hilman khil...@deeprootsystems.com [121105 16:58]: Hi Tony, Here's a couple more trivial fixes for v3.7-rc. Thanks, Kevin The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.7-rc5-fixes-pm for you to fetch changes up to 73c503cb981394872db41dd5cde385cb5373b4b9: ARM: OMAP4: PM: fix regulator name for VDD_MPU (2012-11-05 16:30:29 -0800) Minor OMAP PM fixes for v3.7-rc Thanks pulling into omap-for-v3.7-rc4/fixes. 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren t...@atomide.com wrote: * Grant Likely grant.lik...@secretlab.ca [121106 03:16]: On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Another can of worms is the pinctrl nodes. Yes... new pinctrl data would need to trigger adding new data to pinctrl. I don't know if the pinctrl api supports that. The actual pins stay the same, just their configuration changes. AFAIK all that is already supported using the pinctrl framework. For example, considering hotplugging capes on the beaglebone: 1. You need to map all the sensible modes for the pins exposed to the capes in the board specific .dts file. This will add roughly 4 x nr_capbus_pins named modes in the .dts file so not too bad. 2. Claim all the capebus pins during the capbus driver probe and set them to some safe mode. 3. Try to detect the connected cape(s) over i2c. 4. Use pinctr_select_state to set the desired modes for the pins used by the cape(s). 5. Enable capebus regulators and clocks etc. 6. Load the driver modules for whatever omap internal devices the cape supports. You could also claim the pin for the omap internal devices instead of claiming them in the capebus, but then things can get messy with binding and unbinding the drivers. So just claiming all the pins in the capebus probably keeps things simpler. That assumes that for a particular external bus, certain pins aren't already shared with functions already on the board, for instance if an I²C bus brought out to the external bus already has a chip connected to it. -- 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 6, 2012, at 12:14 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Grant, On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. Jane solves this problem by storing an FDT overlay for each cape in the root filesystem. When the kernel detects that a cape is installed it reads the cape's eeprom to identify it and uses request_firmware() to obtain the appropriate overlay. Userspace passes the overlay to the kernel in the normal way. If the cape doesn't have an eeprom, then the kernel will still use firmware_request(), but userspace needs to already know which cape is installed. Jane is a really productive hardware engineer - she manages to fix a number of problems with her cape design by spinning different revisions of the cape. Using the flexibility that the DT provides, documents and defines the hardware changes of the cape revisions in the FDT overlay. The loader matches the revision of the cape with the proper FDT overlay so that the drivers are relieved of having to do revision management. Okay By installing dtc on the Pi, Mandy compiles the overlay for her prototype hardware. However, she doesn't have a copy of the Pi's original FDT source, so instead she uses the dtc 'fs' input format to compile the overlay file against the live DT data in /proc. Jane (the cape designer) can use this too. Developing the cape, she really appreciates that she doesn't have to reboot every time she makes a change in the cape hardware. By removing the FDT overlay, compiling with the dtc on the board, and re-inserting the overlay, she can be more productive by waiting less. Yes, but I'll leave this paragraph out of the spec. It isn't significantly different from what is already there. No problem. Johnny, Jane's little son, doesn't know anything about device trees, linux kernel trees, or hard-core s/w engineering. He is a bright kid, and due to the board having a node.js based educational electronic design kit, he can use the web-based simplified development environment, that allows him graphically to connect the parts in his kit. He can save the design and the IDE creates on the fly the DT overlay for later use. Yes. Joanne has purchased one of Jane's capes and packaged it into a rugged case for data logging. As far as Joanne is concerned, the BeagleBone and cape together are a single unit and she'd prefer a single monolithic FDT instead of using an FDT overlay. Option A: Using dtc, she uses the BeagleBone and cape .dts source files to generate a single .dtb for the entire system which is loaded by U-Boot. -or- Unlikely. Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files (instead of .dts files), -or- Possible but low probability. Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. Unlikely for your focus perhaps, but I'm trying to capture all the relevant permutations, and I can guarantee that some people really will want this. If not on the bone, then on some other platform. No problem there. Certainly they are valid scenarios. Summary points: - Create an FDT overlay data format and usage model - SHALL reliable resolve or validate of phandles between base and overlay trees - SHOULD reliably
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Russ,
On Nov 6, 2012, at 8:29 PM, Russ Dill wrote:
On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [121106 03:16]:
On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Another can of worms is the pinctrl nodes.
Yes... new pinctrl data would need to trigger adding new data to
pinctrl. I don't know if the pinctrl api supports that.
The actual pins stay the same, just their configuration
changes. AFAIK all that is already supported using the
pinctrl framework.
For example, considering hotplugging capes on the beaglebone:
1. You need to map all the sensible modes for the pins exposed
to the capes in the board specific .dts file. This will
add roughly 4 x nr_capbus_pins named modes in the .dts file
so not too bad.
2. Claim all the capebus pins during the capbus driver probe
and set them to some safe mode.
3. Try to detect the connected cape(s) over i2c.
4. Use pinctr_select_state to set the desired modes for
the pins used by the cape(s).
5. Enable capebus regulators and clocks etc.
6. Load the driver modules for whatever omap internal
devices the cape supports.
You could also claim the pin for the omap internal
devices instead of claiming them in the capebus, but then
things can get messy with binding and unbinding the
drivers. So just claiming all the pins in the capebus
probably keeps things simpler.
That assumes that for a particular external bus, certain pins aren't
already shared with functions already on the board, for instance if an
I²C bus brought out to the external bus already has a chip connected
to it.
This is our case on the bone. We don't enable the peripheral until
a cape that references it is enabled.
I don't think that very big changes are going to be needed TBH.
So now we use:
am3358_pinmux: pinmux@44e10800 {
bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins {
pinctrl-single,pins =
0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT |
MODE7 */
0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT |
MODE7 */
;
};
};
And in the cape definition:
pinctrl-0 = bone_geiger_cape_pins;
Ideally if we could do this in the cape definition:
cape_pinmux {
parent = am3358_pinmux;
bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins {
pinctrl-single,pins =
0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT |
MODE7 */
0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT |
MODE7 */
;
};
pinctrl-0 = bone_geiger_cape_pins;
It would be just fine.
Regards
-- Pantelis
--
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 gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
On 11/06/2012 12:00 PM, Matthieu CASTET wrote:
Jon Hunter a écrit :
On 11/06/2012 10:44 AM, Matthieu CASTET wrote:
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..34ca454 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,8 @@ struct gpmc_timings {
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
+ u16 cycle2cycledelay; /* CYCLE2CYCLEDELAY */
+ u16 busturnaround; /* BUSTURNAROUND */
So you should be able to move these out of OMAP3430 specific as they are
generic.
Thanks for the quick review.
I will post another patch, unless this is already done in Afzal patch (Is
there
a tree where I can get Afzal pending patches ?)
Afzal keeps his kernel tree on gitorious [1]. However, I am not sure
what Afzal's plans are for the remaining patches not yet merged and
which branch you should look at (I have a lot of problems viewing
anything on gitorious these days).
Afzal, let us know how you prefer to handle this.
Cheers
Jon
[1] http://gitorious.org/x0148406-public/linux-kernel
--
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: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
Hi, On Tue, Nov 06, 2012 at 10:42:27AM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121106 10:41]: * Felipe Balbi ba...@ti.com [121106 03:40]: Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz min...@mina86.com I need more Acks here. Only got one from Nicolas. Anyone else ? For omaps: Acked-by: Tony Lindgren t...@atomide.com Heh I guess no omap changes there, so probably not worth adding then. omap1 is old, but it's still omap :-) arch/arm/configs/omap1_defconfig |3 +-- -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Felipe Balbi ba...@ti.com [121106 12:40]: Hi, On Tue, Nov 06, 2012 at 10:42:27AM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121106 10:41]: * Felipe Balbi ba...@ti.com [121106 03:40]: Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz min...@mina86.com I need more Acks here. Only got one from Nicolas. Anyone else ? For omaps: Acked-by: Tony Lindgren t...@atomide.com Heh I guess no omap changes there, so probably not worth adding then. omap1 is old, but it's still omap :-) arch/arm/configs/omap1_defconfig |3 +-- Oh OK so it was not a spurious ack after all :) 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 6, 2012, at 12:14 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: For hot-plugging, you need it. Whether kernel code can deal with large parts of the DT going away... How about we use the dead properties method and move/tag the removed modes as such, and not really remove them. Nodes already use krefs, and I'm thinking about making them kobjects so that they appear in sysfs and we'll have some tools to figure out when reference counts don't get decremented properly. From the little I've looked in the of code, and the drivers, it's going to be pretty bad. I don't think all users take references properly, and we have a big global lock for accessing the DT. I'm a lot more optimistic on this front... I wrote a patch today to make the change and took some measurements: On the versatile express qemu model I measured the free memory with /proc/device-tree, with /sys/device-tree, and with both. Here's what I found: /proc/device-tree only: 114776kB free /sys/device-tree only: 114792kB free both enabled: 114716kB free The back of a napkin calculation indicates that on this platform /proc/devicetree costs 76kB and /sys/device-tree costs 60kb. I'm happy to see that using /sys instead of /proc appears to be slightly cheaper which makes it easier to justify the change. The diffstat makes me even happier: arch/arm/plat-omap/Kconfig|1 - arch/powerpc/platforms/pseries/dlpar.c| 23 --- arch/powerpc/platforms/pseries/reconfig.c | 40 -- drivers/of/Kconfig|8 drivers/of/base.c | 116 drivers/of/fdt.c |5 ++- fs/proc/Makefile |1 - fs/proc/proc_devtree.c| 13 +- fs/proc/root.c|4 +- include/linux/of.h| 35 include/linux/proc_fs.h | 16 include/linux/string.h| 11 + 12 files changed, 107 insertions(+), 166 deletions(-) There are still a few odds and ends that need to be tidied up, but I'll get it out for review shortly. I've not touched the sparc code yet, and I need to take another look over the existing OF_DYNAMIC code. I think that CONFIG_OF_DYNAMIC will probably go away and the add node/property functions will get used by fdt.c and pdt.c for initial construction of the device tree. Adding and removing nodes at runtime as part of the normal operation of the system (and not as something that happens once in a blue moon under controlled conditions) will uncover lots of bugs. I'm hoping so! Its time to clean that mess up. :-) Fortunately adding nodes is not where we're going to have problems. The problems will be on node removal. Addition-only at least means we can have something useful before hunting down and squashing all the bugs. So let's think about locking too Yes, the locking does need to be sorted out. g. -- 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Tue, Nov 6, 2012 at 8:45 PM, Grant Likely grant.lik...@secretlab.ca wrote: The back of a napkin calculation indicates that on this platform /proc/devicetree costs 76kB and /sys/device-tree costs 60kb. I'm happy to see that using /sys instead of /proc appears to be slightly cheaper which makes it easier to justify the change. The diffstat makes me even happier: arch/arm/plat-omap/Kconfig|1 - arch/powerpc/platforms/pseries/dlpar.c| 23 --- arch/powerpc/platforms/pseries/reconfig.c | 40 -- drivers/of/Kconfig|8 drivers/of/base.c | 116 drivers/of/fdt.c |5 ++- fs/proc/Makefile |1 - fs/proc/proc_devtree.c| 13 +- fs/proc/root.c|4 +- include/linux/of.h| 35 include/linux/proc_fs.h | 16 include/linux/string.h| 11 + 12 files changed, 107 insertions(+), 166 deletions(-) Make that 96 insertions. I got an extra patch caught up in that diffstat. g. -- 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: [PATCHv9 0/8] ARM: OMAP4: core retention support
Tero Kristo t-kri...@ti.com writes: Hi Kevin, On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote: Hi Tero, Tero Kristo t-kri...@ti.com writes: Hi, Changes compared to previous version: - rebased on top of 3.7-rc1 - applies on top of latest func pwrst code (v6) - added back patch #1 to this set (it wasn't queued yet after all) - added patch #7 for fixing a bug in the functional pwrst code - added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not) Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend. Branch also available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.7-rc1-omap4-ret-v9 I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1]. Am I missing some other fixes? Using omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors. [...] This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly. The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle. For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?) I was using mainline u-boot at tag v2012.04.01 when I saw the errors. To check the bootloader, I upgraded to the latest mainline tag (v2012.10) and the problems are gone on both 4430/Panda and 4460/Panda-ES... Interesting. That suggests that there's still some kernel assumptions/dependencies on the bootloader that need to be addressed. Kevin -- 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 3/6] ARM: OMAP: voltage: move voltdm_reset to platform_data header
On 10:49-20121106, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [121105 07:04]: Move voltdm_reset to include/linux/platform_data/voltage-omap.h Acked-by: Jean Pihet j-pi...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/voltage.h |1 - include/linux/platform_data/voltage-omap.h |1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index af9d469..0665f21 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -149,5 +149,4 @@ int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void *user), int voltdm_for_each_pwrdm(struct voltagedomain *voltdm, int (*fn)(struct voltagedomain *voltdm, struct powerdomain *pwrdm)); -void voltdm_reset(struct voltagedomain *voltdm); #endif diff --git a/include/linux/platform_data/voltage-omap.h b/include/linux/platform_data/voltage-omap.h index 5be4d5d..4eb3d43 100644 --- a/include/linux/platform_data/voltage-omap.h +++ b/include/linux/platform_data/voltage-omap.h @@ -36,4 +36,5 @@ int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); +void voltdm_reset(struct voltagedomain *voltdm); #endif The include/linux/platform_data/voltage-omap.h should only contain pure platform_data, these should internal defines to the driver. considering the move took place as part of: commit 2203747c97712975accc5e69bdaf1ad38a691635 (ARM: omap: move platform_data definitions) I suppose we should clean up the following as well include/linux/platform_data/dsp-omap.h - has function - reserve include/linux/platform_data/mtd-nand-omap2.h - has function -init include/linux/platform_data/mtd-onenand-omap2.h - has function -init include/linux/platform_data/remoteproc-omap.h - has function - reserve Looks like there are other things there too that's not platform data: struct voltagedomain *voltdm_lookup(const char *name); int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); Can you please add a patch fixing that ASAP? Agreed include/linux/platform_data/voltage-omap.h has more functions as well. Considering it did: rename arch/arm/plat-omap/include/plat/voltage.h = include/linux/platform_data/voltage-omap.h Where do we move these functions to? drivers/power/avs/smartreflex.c needs: omap_voltage_get_voltdata and drivers/power/avs/smartreflex-class3.c will need voltdm_reset and voltdm_get_voltage -- 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: [PATCHv9 2/8] ARM: OMAP4: PM: add errata support
Kevin Hilman khil...@deeprootsystems.com writes: Tero Kristo t-kri...@ti.com writes: Added similar PM errata flag support as omap3 has. This should be used in similar manner, set the flags during init time, and check the flag values during runtime. Signed-off-by: Tero Kristo t-kri...@ti.com These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going to queue these up as fixes. However, since they're not technically regressions, it may be too late to get them in for v3.7, but they'll be in for v3.8 for sure. To be more specific, I'm planning on queuing patches 2, 3 and 6 as fixes for v3.8 (branch: for_3.8/fixes/pm). Paul has already queued patch 1, so that leaves patches 4, 5, 7 8. I think we can get this series in for v3.8 if we drop the functional pwrst dependency. To test, I dropped patches 5 7, and tested on 4430/Panda and 4460/Panda-ES (with latest mainline u-boot) and CORE is hitting retention just fine in suspend. If you can respin patch 8 based on the feedback from Felipe, I'll queue up patches 4 8 for v3.8 as well, then we'll at least have CORE retention in suspend in mainline. Then, the rest can be done when functional pwrsts are ready. Kevin P.S. do you have any patches to add any OMAP4 CPUidle support for CORE retention? Paul has already queued patch 1, and that leaves the -- 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: OMAP: second set of PRCM cleanups for 3.8
* Paul Walmsley p...@pwsan.com [121101 05:18]: Hi Tony The following changes since commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33: Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm (2012-10-26 13:32:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b-for-3.8 for you to fetch changes up to f17d60d20eb8e679cdd1e9d507394237e58ce0d8: Tried pulling but.. These patches remove the use of omap_prcm_get_reset_sources() from the OMAP watchdog driver, and remove mach-omap2/prcm.c and plat-omap/include/plat/prcm.h. Basic test logs for this branch on top of Tony's cleanup-prcm branch at commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33 are here: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/ However, cleanup-prcm at 7fc54fd3 does not build for several Kconfigs here and doesn't include some fixes that are needed for a successful test. With several reverts, fixes, and workarounds applied, the following test logs were obtained: ..now wondering which configs do not build for you at 7fc54fd3? It builds at least all my test configs. Well at least the ones I have recovered after accidentally deleting some files yesterday, did not have a back up copy of two of them. However if I pull your branch in, build breaks for me for with the rmk-omap3430-ldp-noconfig and rmk-omap4430-sdp-noconfig: arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x48): undefined reference to `omap44xx_restart' 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/06/2012 12:41 PM, Pantelis Antoniou wrote:
Hi Russ,
On Nov 6, 2012, at 8:29 PM, Russ Dill wrote:
On Tue, Nov 6, 2012 at 10:35 AM, Tony Lindgren t...@atomide.com wrote:
* Grant Likely grant.lik...@secretlab.ca [121106 03:16]:
On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Another can of worms is the pinctrl nodes.
Yes... new pinctrl data would need to trigger adding new data to
pinctrl. I don't know if the pinctrl api supports that.
The actual pins stay the same, just their configuration
changes. AFAIK all that is already supported using the
pinctrl framework.
For example, considering hotplugging capes on the beaglebone:
...
That assumes that for a particular external bus, certain pins aren't
already shared with functions already on the board, for instance if an
I²C bus brought out to the external bus already has a chip connected
to it.
This is our case on the bone. We don't enable the peripheral until
a cape that references it is enabled.
I don't think that very big changes are going to be needed TBH.
...
Ideally if we could do this in the cape definition:
cape_pinmux {
parent = am3358_pinmux;
I think the cape overlay would simply add nodes to the existing pin
controller node, so I'd presume you would replace the two lines
immediately above with:
am3358_pinmux: pinmux {
bone_dvi_cape_led_pins: pinmux_bone_dvi_cape_led_pins {
pinctrl-single,pins =
0x48 0x07 /* gpmc_a2.gpio1_18, OUTPUT |
MODE7 */
0x4c 0x07 /* gpmc_a3.gpio1_19, OUTPUT |
MODE7 */
;
};
pinctrl-0 = bone_geiger_cape_pins;
--
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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
Interesting. This just came up internally at NVIDIA within the last
couple weeks, and was discussed on the U-Boot mailing list very recently
too:
http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227
(it spills into the November archive too)
For these cases it is proposed to implement an overlay feature for the
so that the initial device tree data can be modified by userspace at
I don't know if you're maintaining this as a document and taking patches
to it, but if so:
for the so split across those two lines.
Jane solves this problem by storing an FDT overlay for each cape in the
root filesystem. When the kernel detects that a cape is installed it
reads the cape's eeprom to identify it and uses request_firmware() to
obtain the appropriate overlay. Userspace passes the overlay to the
kernel in the normal way. If the cape doesn't have an eeprom, then the
kernel will still use firmware_request(), but userspace needs to already
know which cape is installed.
As mentioned by Pantelis, multiple versions of a board is also very
common. We already have the following .dts files in the kernel where
this applies, for the main board even:
arch/arm/boot/dts/tegra30-cardhu.dtsi
arch/arm/boot/dts/tegra30-cardhu-a02.dts
arch/arm/boot/dts/tegra30-cardhu-a04.dts
Summary points:
- SHOULD reliably handle changes between different underlying overlays
(ie. what happens to existing .dtb overly files if the structure of
the dtb it is layered over changes. If not possible, then SHALL
detect when the base tree doesn't match and refuse to apply the
overlay.
Perhaps use (versioned) DT bindings to represent the interface between
the two .dts files? See the links to the U-Boot mailing list discussions
below?
- What is the model for overlays?
- Can an overlay modify existing properties?
- Can an overlay add new properties to existing nodes?
- Can an overlay delete existing nodes/properties?
This proposal is very oriented at an overlay-based approach. I'm not
totally convinced that a pure overlay approach (as in how dtc does
overlayed DT nodes) will be flexible enough, but would love to be
persuaded. Again see below.
It may be sufficient to solve it by making the phandle values less
volatile. Right now dtc generates phandles linearly. Generated phandles
could be overridden with explicit phandle properties, but it isn't a
fantastic solution. Perhaps generating the phandle from a hash of the
node name would be sufficient.
Node names don't have to be unique though right; perhaps hash the
path-name instead of the node-name? But then, why not just reference by
path name; similar to {/path/to/node} rather than label?
This handles many of the use cases, but it assumes that an overlay is
board specific. If it ever is required to support multiple base boards
with a single overlay file then there is a problem. The .dtb overlays
generated in this manor cannot handle different phandles or nodes that
are in a different place. On the other hand, the overlay source files
should have no problem being compiled for multiple targets.
s/manor/manner/
I do rather suspect this use-case is quite common. NVIDIA certainly has
a bunch of development boards with pluggable
PMIC/audio/WiFi/display/..., and I believe there's some ability to
re-use the pluggable components with a variety of base-boards.
Given people within NVIDIA started talking about this recently, I asked
them to enumerate all the boards we have that support pluggable
components, and how common it is that some boards support being plugged
into different main boards. I don't know when that enumeration will
complete (or even start) but hopefully I can provide some feedback on
how common the use-case is for us once it's done.
My earlier thoughts on how to support this included explicit
inter-board/-component connector objects in the .dts files that allow
renaming of GPIOs, I2C buses, regulators, etc.:
http://lists.denx.de/pipermail/u-boot/2012-October/138476.html
http://lists.denx.de/pipermail/u-boot/2012-November/138925.html
--
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] OMAP: PM: misc. fixes for v3.8
Tony, Here's a small series that fixes some errata to make suspend/resume work on OMAP4460. This is not a regression and has been broken for awhile, so this is v3.8 material, not v3.7. Kevin The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-fixes-pm for you to fetch changes up to cd8ce159031813eb870a5f3d5b27c3be36cd6e3a: ARM: OMAP4: retrigger localtimers after re-enabling gic (2012-11-05 14:26:43 -0800) Some non-regression fixes for OMAP4460 PM support. Colin Cross (1): ARM: OMAP4: retrigger localtimers after re-enabling gic Santosh Shilimkar (1): ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change. Tero Kristo (1): ARM: OMAP4: PM: add errata support arch/arm/mach-omap2/common.h | 4 +++ arch/arm/mach-omap2/omap-headsmp.S| 38 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 9 ++- arch/arm/mach-omap2/omap-smp.c| 39 +++- arch/arm/mach-omap2/omap4-common.c| 42 ++- arch/arm/mach-omap2/pm.h | 9 +++ arch/arm/mach-omap2/pm44xx.c | 1 + 7 files changed, 139 insertions(+), 3 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
[GIT PULL] OMAP: PM: cleanups for v3.8
Tony, Here is some PM related cleanup targetted for v3.8. Kevin The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-cleanup-pm for you to fetch changes up to 9bb053787d5ca12ec388bb5f871c79ffb83762ab: ARM: OMAP2+: PM: VP: minor pr_warn updates (2012-10-25 14:32:34 -0700) Minor pr_warn() cleanup for OMAP2+ Voltage Processor (VP) Nishanth Menon (1): ARM: OMAP2+: PM: VP: minor pr_warn updates arch/arm/mach-omap2/vp.c | 13 ++--- 1 file changed, 6 insertions(+), 7 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
[GIT PULL] OMAP: PM: SmartReflex updates for v3.8
Tony, Here's some minor platform_data related updates for SR for v3.8. Kevin The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-sr for you to fetch changes up to 98aed08e16c5f18d0c31fc07127bc163ccd0d04c: ARM: OMAP: SmartReflex: pass device dependent data via platform data (2012-10-15 15:22:24 -0700) OMAP: SmartReflex: pass device-independent data via platform_data Jean Pihet (2): ARM: OMAP: hwmod: align the SmartReflex fck names ARM: OMAP: SmartReflex: pass device dependent data via platform data arch/arm/mach-omap2/clock33xx_data.c | 12 +++ arch/arm/mach-omap2/clock3xxx_data.c | 12 +++ arch/arm/mach-omap2/clock44xx_data.c | 6 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 ++--- arch/arm/mach-omap2/sr_device.c| 13 +++ drivers/power/avs/smartreflex.c| 54 ++ include/linux/power/smartreflex.h | 14 ++-- 7 files changed, 61 insertions(+), 58 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
[GIT PULL] OMAP: PM: voltage layer updates for v3.8
Tony, Here's a set of voltage layer updates for v3.8. This implements all the framework changes necessary to get auto-ret/auto-off working, but the main change to enable auto-ret/auto-off is awaiting the functional power state changes that are still under review/rework. Also, this fixes that pesky VC warning about I2C config not matching other channels that was reported by Russell. Kevin The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-voltage for you to fetch changes up to df7cded30ced539d3b4e6bae9f3011d98c069d41: ARM: OMAP4: OPP: add OMAP4460 definitions (2012-11-05 15:31:49 -0800) OMAP voltage layer updates towards supporting auto-retention/auto-off Nishanth Menon (1): ARM: OMAP3+: PM: VP: use uV for max and min voltage limits Tero Kristo (13): ARM: OMAP: voltage: renamed vp_vddmin and vp_vddmax fields ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomains ARM: OMAP3: VC: calculate ramp times ARM: OMAP4: voltage: add support for VOLTSETUP_x_OFF register ARM: OMAP4: VC: calculate ramp times ARM: OMAP: add support for oscillator setup ARM: OMAP3+: vp: use new vp_params for calculating vddmin and vddmax ARM: OMAP3+: voltage: use oscillator data to calculate setup times ARM: OMAP: TWL: change the vddmin / vddmax voltages to spec ARM: OMAP3+: voltage: remove unused volt_setup_time parameter ARM: OMAP4: vc: fix channel configuration ARM: OMAP4: VC: setup I2C parameters based on board data ARM: OMAP4: TWL: enable high speed mode for PMIC communication Vishwanath Sripathy (1): ARM: OMAP4: OPP: add OMAP4460 definitions arch/arm/mach-omap2/control.h | 1 + arch/arm/mach-omap2/omap_opp_data.h | 9 +- arch/arm/mach-omap2/omap_twl.c| 73 + arch/arm/mach-omap2/opp4xxx_data.c| 98 +- arch/arm/mach-omap2/pm.c | 30 ++ arch/arm/mach-omap2/pm.h | 10 + arch/arm/mach-omap2/vc.c | 451 -- arch/arm/mach-omap2/vc.h | 8 +- arch/arm/mach-omap2/vc3xxx_data.c | 22 ++ arch/arm/mach-omap2/vc44xx_data.c | 28 ++ arch/arm/mach-omap2/voltage.h | 44 ++- arch/arm/mach-omap2/voltagedomains3xxx_data.c | 5 + arch/arm/mach-omap2/voltagedomains44xx_data.c | 23 +- arch/arm/mach-omap2/vp.c | 6 +- arch/arm/mach-omap2/vp.h | 7 + arch/arm/mach-omap2/vp3xxx_data.c | 10 + arch/arm/mach-omap2/vp44xx_data.c | 15 + 17 files changed, 725 insertions(+), 115 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: [GIT PULL] ARM: OMAP: DTS for 3.8
* Benoit Cousson b-cous...@ti.com [121101 10:16]: Hi Tony, Please pull some more OMAP5 and AM33xx data for 3.8. The branch contains as well some cleanup and the omap3-beagle support since the previous one was in fact a beagle-xm. Thanks pulling into omap-for-v3.8/dt. 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
OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups
Hello, I just noticed that the kernel wakeup from suspend using RTC is broken after I upgraded u-boot from v2012.04.01 to v2012.10 on my OMAP4430/Panda and OMAP4460/Panda-ES. I haven't isolated the cause yet, but am hoping someone might have a pointer about where to start digging. Kevin -- 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: OMAP: Timer and Counter DT Updates for v3.8
* Jon Hunter jon-hun...@ti.com [121102 12:01]: Hi Tony, Please pull the remaining patches to migrate OMAP timers and counters over to use device-tree. I recommend applying this after Benoit's DT series for v3.8 [1]. This branch contains ... - Handling OMAP3 secure timers with device-tree - Requesting timer by capability/feature - Adds new DT machine descriptor for OMAP3 GP devices - Look-up of clocksource/events timers from DT - Migrate dmtimer driver to use DT Cheers Jon [1] http://marc.info/?l=linux-omapm=135179007210696w=2 The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64: Linux 3.7-rc3 (2012-10-28 12:24:48 -0700) are available in the git repository at: g...@github.com:jonhunter/linux.git dev-dt-timer Thanks pulling into omap-for-v3.8/dt branch. Regards, Tony for you to fetch changes up to 9883f7c8dd21acb90697582ca331f3f8a66ac054: ARM: OMAP2+: Add device-tree support for 32kHz counter (2012-11-02 13:16:31 -0500) Jon Hunter (5): ARM: OMAP3: Dynamically disable secure timer nodes for secure devices ARM: OMAP: Add function to request a timer by capability ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP devices ARM: OMAP: Add DT support for timer driver ARM: OMAP2+: Add device-tree support for 32kHz counter arch/arm/mach-omap2/board-generic.c | 17 +++ arch/arm/mach-omap2/timer.c | 203 - arch/arm/plat-omap/dmtimer.c | 93 - arch/arm/plat-omap/include/plat/dmtimer.h |1 + 4 files changed, 275 insertions(+), 39 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: OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups
+ Sricharan, On Tuesday 06 November 2012 06:46 PM, Kevin Hilman wrote: Hello, I just noticed that the kernel wakeup from suspend using RTC is broken after I upgraded u-boot from v2012.04.01 to v2012.10 on my OMAP4430/Panda and OMAP4460/Panda-ES. I haven't isolated the cause yet, but am hoping someone might have a pointer about where to start digging. Kevin -- 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 -- 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] OMAP: PM: misc. fixes for v3.8
* Kevin Hilman khil...@deeprootsystems.com [121106 15:49]: Tony, Here's a small series that fixes some errata to make suspend/resume work on OMAP4460. This is not a regression and has been broken for awhile, so this is v3.8 material, not v3.7. Kevin The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-fixes-pm Thanks pulling into omap-for-v3.8/fixes-non-critical. Regards, Tony for you to fetch changes up to cd8ce159031813eb870a5f3d5b27c3be36cd6e3a: ARM: OMAP4: retrigger localtimers after re-enabling gic (2012-11-05 14:26:43 -0800) Some non-regression fixes for OMAP4460 PM support. Colin Cross (1): ARM: OMAP4: retrigger localtimers after re-enabling gic Santosh Shilimkar (1): ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change. Tero Kristo (1): ARM: OMAP4: PM: add errata support arch/arm/mach-omap2/common.h | 4 +++ arch/arm/mach-omap2/omap-headsmp.S| 38 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 9 ++- arch/arm/mach-omap2/omap-smp.c| 39 +++- arch/arm/mach-omap2/omap4-common.c| 42 ++- arch/arm/mach-omap2/pm.h | 9 +++ arch/arm/mach-omap2/pm44xx.c | 1 + 7 files changed, 139 insertions(+), 3 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/6/2012 12:37 PM, Stephen Warren wrote:
On 11/05/2012 01:40 PM, Grant Likely wrote:
Hey folks,
As promised, here is my early draft to try and capture what device
tree overlays need to do and how to get there. Comments and
suggestions greatly appreciated.
Interesting. This just came up internally at NVIDIA within the last
couple weeks, and was discussed on the U-Boot mailing list very recently
too:
http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227
(it spills into the November archive too)
For these cases it is proposed to implement an overlay feature for the
so that the initial device tree data can be modified by userspace at
I don't know if you're maintaining this as a document and taking patches
to it, but if so:
for the so split across those two lines.
Jane solves this problem by storing an FDT overlay for each cape in the
root filesystem. When the kernel detects that a cape is installed it
reads the cape's eeprom to identify it and uses request_firmware() to
obtain the appropriate overlay. Userspace passes the overlay to the
kernel in the normal way. If the cape doesn't have an eeprom, then the
kernel will still use firmware_request(), but userspace needs to already
know which cape is installed.
As mentioned by Pantelis, multiple versions of a board is also very
common. We already have the following .dts files in the kernel where
this applies, for the main board even:
arch/arm/boot/dts/tegra30-cardhu.dtsi
arch/arm/boot/dts/tegra30-cardhu-a02.dts
arch/arm/boot/dts/tegra30-cardhu-a04.dts
Summary points:
- SHOULD reliably handle changes between different underlying overlays
(ie. what happens to existing .dtb overly files if the structure of
the dtb it is layered over changes. If not possible, then SHALL
detect when the base tree doesn't match and refuse to apply the
overlay.
Perhaps use (versioned) DT bindings to represent the interface between
the two .dts files? See the links to the U-Boot mailing list discussions
below?
- What is the model for overlays?
- Can an overlay modify existing properties?
- Can an overlay add new properties to existing nodes?
- Can an overlay delete existing nodes/properties?
This proposal is very oriented at an overlay-based approach. I'm not
totally convinced that a pure overlay approach (as in how dtc does
overlayed DT nodes) will be flexible enough, but would love to be
persuaded. Again see below.
An overlay approach will not be powerful enough to solve the sorts of
problems that occur when a product goes into full production, becomes a
family, and starts to evolve. Issues like second-source parts that
aren't quite compatible and need to be detected and reported,
board-stuff options for different customer profiles, speed grades of
parts that aren't properly probeable but instead need to be identified
by some subterfuge, the list of tedious issues goes on and on.
It's nice to pretend that the world fits into a few coherent simple
use cases, but 30 years of experience shipping computer product families
proves otherwise. You need a programming language to solve the full
set of problems - which I why the device tree is designed so it can
be generated and modified by a program.
It may be sufficient to solve it by making the phandle values less
volatile. Right now dtc generates phandles linearly. Generated phandles
could be overridden with explicit phandle properties, but it isn't a
fantastic solution. Perhaps generating the phandle from a hash of the
node name would be sufficient.
Node names don't have to be unique though right; perhaps hash the
path-name instead of the node-name? But then, why not just reference by
path name; similar to {/path/to/node} rather than label?
This handles many of the use cases, but it assumes that an overlay is
board specific. If it ever is required to support multiple base boards
with a single overlay file then there is a problem. The .dtb overlays
generated in this manor cannot handle different phandles or nodes that
are in a different place. On the other hand, the overlay source files
should have no problem being compiled for multiple targets.
s/manor/manner/
I do rather suspect this use-case is quite common. NVIDIA certainly has
a bunch of development boards with pluggable
PMIC/audio/WiFi/display/..., and I believe there's some ability to
re-use the pluggable components with a variety of base-boards.
Given people within NVIDIA started talking about this recently, I asked
them to enumerate all the boards we have that support pluggable
components, and how common it is that some boards support being plugged
into different main boards. I don't know when that enumeration will
complete (or even start) but hopefully I can provide some feedback on
how common the use-case is for us once it's done.
My earlier thoughts on how to support this included explicit
inter-board/-component
Re: [PATCH 0/6] OMAPDSS: enable DSS for Panda SDP with devtree
* Tomi Valkeinen tomi.valkei...@ti.com [121105 05:16]: Hi, OMAPDSS device tree support is still some way in the future. Tony has requested to get DSS working for Panda SDP boards with DT kernel, so that we'll have fully working boards with DT. This series makes a few hacks to get a working display on OMAP4 Panda and SDP boards. The idea is to setup the omapdss with the non-DT method, creating the omapdss devices and passing platform data to them. This setup code is called from board-generic for Panda and SDP boards. There was one problem with this approach: omapdss cannot get regulators using the omapdss's names fro the regulators. Thus there's a hack patch to get the regulators using the OMAP4 native regulator names, thus circumventing the problem. Tony, if these look good, how do you want to merge these? There are three parts here, and I think they can be merged independently if so wished: * .dts changes for the pinmuxing (2 patches) Let's let Benoit queue these. * dss-common.c and board-generic.c changes (3 patches) And I can take these. * DSS hack for the regulators (1 patch) And you can take this. If one of those parts is missing, DSS won't start with DT kernel, but otherwise there shouldn't be any problems. So to avoid conflicts, I suggest that you take the first two parts, and I'll merge the DSS hack via omapdss tree. Cool thanks for doing this. Looks OK to me until we have the DT bindings ready. 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/2] mailbox: OMAP: introduce mailbox framework
Hi Stephen, On 5 November 2012 21:40, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote: Actually moving it from plat-omap, as this framework/driver code is supposed to be under drivers/ folder. The framework should work with the current supported OMAP processors (OMAP1+) that have mailbox and can be used as a method of interprocessor communication. The mailbox hardware (in OMAP) uses a queued mailbox-interrupt mechanism that provides a communication channel between processors through a set of registers and their associated interrupt signals by sending and receiving messages. diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? Is this a generic interface to any mailbox driver? If so, then I don't think having omap in the symbol names is appropriate. If the header is specific to the OMAP driver, I don't think using the very generic filename mailbox.h is appropriate; use omap_mailbox.h instead? It was a mixture between the two, the next patch splits the API from the mailbox driver interfaces. I kept the files named as plain mailbox.[ch], in hopes that we could progress with the cleanup after moving the files from plat-omap, as it seems they interfere with the current single Image effort, but if it is preferred (as it seems to be) I can resend again after removing the omap_ prefixes from the intended-to-be generic code. Thanks, Omar -- 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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
Bedia, Vaibhav vaibhav.be...@ti.com writes: On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote: [...] Also, if there are drivers for these devices, won't this interfere? Hmm, I can think of the following scenarios 1. Runtime PM adapted drivers are compiled in - We'll have to ensure that in their suspend callbacks they end up doing omap_hwmod_idle() via the runtime PM APIs. That already happens for all omap_devices. In this case the omap_hwmod_enable() followed by omap_hwmod_idle() is not necessary in the PM code. Correct. 2. The drivers are not compiled in - In this case, the hwmod code puts the IPs in standby during bootup so the first suspend-resume iteration will pass. During resuming, the SYSC configuration for forced standby will be lost, Please clarify how the SYSC is lost in this case. so in the subsequent iterations these IPs won't go standby and the hwmod code does not touch them since they never got enabled. In this case we do need the sequence that is there currently. 3. For some reason the respective drivers don't idle the IPs during suspend - (no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think we should abort the suspend process since we know that the suspend is not going to work. Agreed. Is there some other scenario that needs to be covered? You covered the ones I was thinking of. How about adding some flag in hwmod code for handling this? Something similar to what was done for MMC [1]. I think the problem that we have is in some ways similar to the one addressed in [1]. Except that in the absence of drivers, no hwmod code is executed on the suspend/resume path. Kevin -- 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] OMAP: PM: cleanups for v3.8
* Kevin Hilman khil...@deeprootsystems.com [121106 15:51]: Tony, Here is some PM related cleanup targetted for v3.8. Kevin The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-cleanup-pm for you to fetch changes up to 9bb053787d5ca12ec388bb5f871c79ffb83762ab: ARM: OMAP2+: PM: VP: minor pr_warn updates (2012-10-25 14:32:34 -0700) Minor pr_warn() cleanup for OMAP2+ Voltage Processor (VP) Thanks pulling into omap-for-v3.8/pm. 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: [GIT PULL] OMAP: PM: SmartReflex updates for v3.8
* Kevin Hilman khil...@deeprootsystems.com [121106 15:52]: Tony, Here's some minor platform_data related updates for SR for v3.8. Kevin The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-sr for you to fetch changes up to 98aed08e16c5f18d0c31fc07127bc163ccd0d04c: ARM: OMAP: SmartReflex: pass device dependent data via platform data (2012-10-15 15:22:24 -0700) OMAP: SmartReflex: pass device-independent data via platform_data Thanks pulling into omap-for-v3.8/pm. 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: [GIT PULL] OMAP: PM: voltage layer updates for v3.8
* Kevin Hilman khil...@deeprootsystems.com [121106 15:58]: Tony, Here's a set of voltage layer updates for v3.8. This implements all the framework changes necessary to get auto-ret/auto-off working, but the main change to enable auto-ret/auto-off is awaiting the functional power state changes that are still under review/rework. Also, this fixes that pesky VC warning about I2C config not matching other channels that was reported by Russell. Kevin The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-voltage for you to fetch changes up to df7cded30ced539d3b4e6bae9f3011d98c069d41: ARM: OMAP4: OPP: add OMAP4460 definitions (2012-11-05 15:31:49 -0800) OMAP voltage layer updates towards supporting auto-retention/auto-off Thanks pulling into omap-for-v3.8/pm. 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/2] mailbox: OMAP: introduce mailbox framework
Hi Greg, On 6 November 2012 02:59, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote: On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren swar...@wwwdotorg.org wrote: Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? I think the split out of the public header is done in patch 2/2. Yes, but the names are still omap_*, which doesn't make much sense here. Ok, I have no problem with this... I was under the impression that moving this code out of plat-omap was blocking single zImage support hence the minimal changes to move it to drivers/. I will strip the generic portions from omap_ prefixes and resend. Cheers, Omar -- 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/1] ARM: OMAP: Add maintainer entry for IGEP machines
* Javier Martinez Canillas jav...@dowhile0.org [121008 01:49]: Enric and I have been mantained this machine and while we are moving to device trees, it is good that people cc us when reporting bugs or regression on the board file until we have proper DT support. Thanks applying into omap-for-v3.8/board branch. 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 3/6] ARM: OMAP: voltage: move voltdm_reset to platform_data header
* Nishanth Menon n...@ti.com [121106 13:50]: On 10:49-20121106, Tony Lindgren wrote: Looks like there are other things there too that's not platform data: struct voltagedomain *voltdm_lookup(const char *name); int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); Can you please add a patch fixing that ASAP? Agreed include/linux/platform_data/voltage-omap.h has more functions as well. Considering it did: rename arch/arm/plat-omap/include/plat/voltage.h = include/linux/platform_data/voltage-omap.h Where do we move these functions to? drivers/power/avs/smartreflex.c needs: omap_voltage_get_voltdata and drivers/power/avs/smartreflex-class3.c will need voltdm_reset and voltdm_get_voltage How about something local drivers/power/avs/smartreflex.h? 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: [RESEND] [PATCH 3.6.0- 1/6] ARM/omap1: use module_platform_driver macro
* Srinivas KANDAGATLA srinivas.kandaga...@st.com [121012 00:14]:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Sorry for delay on these, we're moving the mailbox code to
live under drivers, so these may need to wait a little bit.
Regards,
Tony
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
arch/arm/mach-omap1/mailbox.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index e962926..45c8719 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -179,19 +179,7 @@ static struct platform_driver omap1_mbox_driver = {
.name = omap-mailbox,
},
};
-
-static int __init omap1_mbox_init(void)
-{
- return platform_driver_register(omap1_mbox_driver);
-}
-
-static void __exit omap1_mbox_exit(void)
-{
- platform_driver_unregister(omap1_mbox_driver);
-}
-
-module_init(omap1_mbox_init);
-module_exit(omap1_mbox_exit);
+module_platform_driver(omap1_mbox_driver);
MODULE_LICENSE(GPL v2);
MODULE_DESCRIPTION(omap mailbox: omap1 architecture specific functions);
--
1.7.0.4
--
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 3/6] ARM: OMAP: voltage: move voltdm_reset to platform_data header
On 17:18-20121106, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [121106 13:50]: On 10:49-20121106, Tony Lindgren wrote: Looks like there are other things there too that's not platform data: struct voltagedomain *voltdm_lookup(const char *name); int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); Can you please add a patch fixing that ASAP? Agreed include/linux/platform_data/voltage-omap.h has more functions as well. Considering it did: rename arch/arm/plat-omap/include/plat/voltage.h = include/linux/platform_data/voltage-omap.h Where do we move these functions to? drivers/power/avs/smartreflex.c needs: omap_voltage_get_voltdata and drivers/power/avs/smartreflex-class3.c will need voltdm_reset and voltdm_get_voltage How about something local drivers/power/avs/smartreflex.h? These APIs are exposed by voltage layer, not smartreflex :( stuff like voltdm_scale will have to be used by regulator logic eventually, so moving to AVS driver header is probably not right. -- 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 3/6] ARM: OMAP: voltage: move voltdm_reset to platform_data header
* Nishanth Menon n...@ti.com [121106 17:30]: On 17:18-20121106, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [121106 13:50]: On 10:49-20121106, Tony Lindgren wrote: Looks like there are other things there too that's not platform data: struct voltagedomain *voltdm_lookup(const char *name); int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); Can you please add a patch fixing that ASAP? Agreed include/linux/platform_data/voltage-omap.h has more functions as well. Considering it did: rename arch/arm/plat-omap/include/plat/voltage.h = include/linux/platform_data/voltage-omap.h Where do we move these functions to? drivers/power/avs/smartreflex.c needs: omap_voltage_get_voltdata and drivers/power/avs/smartreflex-class3.c will need voltdm_reset and voltdm_get_voltage How about something local drivers/power/avs/smartreflex.h? These APIs are exposed by voltage layer, not smartreflex :( stuff like voltdm_scale will have to be used by regulator logic eventually, so moving to AVS driver header is probably not right. Well ideally you'd have some generic API doing it rather than these omap specifc exported functions. Meanwhile, I guess you need to find some suitable location for the header file that works for Rafael. 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
[PATCH 0/4] cpufreq: OMAP: if available, scale the iva coprocessor
The iva coprocessor, available on some omap platforms, shares a voltage domain with the mpu. If cpufreq is active and the mpu processor is scaled down, the iva coprocessor should also be scaled. The goal is to make sure we do not ramp down the voltage on the domain and affect clocking on the iva coprocessor leading to a dsp crash. I only have access to an omap3evm-ish device, so I do not know what the iva clock name is for omap24xx and omap44xx. This detail can be added later if the general approach is approved. I have tested a version of this patch against the linux-3.3 kernel, so this my attempt at a forward port against the current mainline. I have based my patch series against linux-omap-pm/pm-next. Joshua Emele (4): cpufreq: OMAP: if an iva clock name is specified, load iva resources cpufreq: OMAP: for omap3 devices, specify the iva clock name cpufreq: OMAP: ensure the iva coprocessor is at the same opp as the mpu cpufreq: OMAP: scale the iva coprocessor if available drivers/cpufreq/omap-cpufreq.c | 113 +-- 1 files changed, 95 insertions(+), 18 deletions(-) -- 1.7.6.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
[PATCH 1/4] cpufreq: OMAP: if an iva clock name is specified, load iva resources
Signed-off-by: Joshua Emele jem...@gmail.com
---
drivers/cpufreq/omap-cpufreq.c | 73 ---
1 files changed, 60 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..1621208 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -50,11 +50,11 @@ static DEFINE_PER_CPU(struct lpj_info, lpj_ref);
static struct lpj_info global_lpj_ref;
#endif
-static struct cpufreq_frequency_table *freq_table;
+static struct cpufreq_frequency_table *freq_table, *iva_freq_table;
static atomic_t freq_table_users = ATOMIC_INIT(0);
-static struct clk *mpu_clk;
-static char *mpu_clk_name;
-static struct device *mpu_dev;
+static struct clk *mpu_clk, *iva_clk;
+static char *mpu_clk_name, *iva_clk_name;
+static struct device *mpu_dev, *iva_dev;
static struct regulator *mpu_reg;
static int omap_verify_speed(struct cpufreq_policy *policy)
@@ -199,8 +199,49 @@ done:
static inline void freq_table_free(void)
{
- if (atomic_dec_and_test(freq_table_users))
+ if (atomic_dec_and_test(freq_table_users)) {
opp_free_cpufreq_table(mpu_dev, freq_table);
+ opp_free_cpufreq_table(iva_dev, iva_freq_table);
+ }
+}
+
+static inline void clk_free(void)
+{
+ if (mpu_clk) {
+ clk_put(mpu_clk);
+ mpu_clk = NULL;
+ }
+ if (iva_clk) {
+ clk_put(iva_clk);
+ iva_clk = NULL;
+ }
+}
+
+static int __cpuinit omap_iva_init(struct cpufreq_policy *policy)
+{
+ int result;
+ if (!iva_clk_name) {
+ pr_info(%s: iva unavailable\n, __func__);
+ return 0;
+ }
+ iva_dev = omap_device_get_by_hwmod_name(iva);
+ if (!iva_dev) {
+ pr_err(%s: unable to get the iva device\n, __func__);
+ return -EINVAL;
+ }
+ iva_clk = clk_get(NULL, iva_clk_name);
+ if (IS_ERR(iva_clk)) {
+ dev_err(iva_dev, %s: cpu%d: %s clock unavailable\n,
+ __func__, policy-cpu, iva_clk_name);
+ return PTR_ERR(iva_clk);
+ }
+ result = opp_init_cpufreq_table(iva_dev, iva_freq_table);
+ if (result) {
+ dev_err(iva_dev, %s: cpu%d: failed creating freq table[%d]\n,
+ __func__, policy-cpu, result);
+ return result;
+ }
+ return 0;
}
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
@@ -218,13 +259,19 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
policy-cur = policy-min = policy-max = omap_getspeed(policy-cpu);
- if (atomic_inc_return(freq_table_users) == 1)
+ if (atomic_inc_return(freq_table_users) == 1) {
result = opp_init_cpufreq_table(mpu_dev, freq_table);
-
- if (result) {
- dev_err(mpu_dev, %s: cpu%d: failed creating freq table[%d]\n,
- __func__, policy-cpu, result);
- goto fail_ck;
+ if (result) {
+ dev_err(mpu_dev, %s: cpu%d: failed creating freq
table[%d]\n,
+ __func__, policy-cpu, result);
+ goto fail_ck;
+ }
+ result = omap_iva_init(policy);
+ if (result) {
+ pr_err(%s: cpu%d: failed to initialize iva[%d]\n,
+ __func__, policy-cpu, result);
+ goto fail_table;
+ }
}
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -257,14 +304,14 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
fail_table:
freq_table_free();
fail_ck:
- clk_put(mpu_clk);
+ clk_free();
return result;
}
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
freq_table_free();
- clk_put(mpu_clk);
+ clk_free();
return 0;
}
--
1.7.6.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
[PATCH 2/4] cpufreq: OMAP: for omap3 devices, specify the iva clock name
Signed-off-by: Joshua Emele jem...@gmail.com
---
drivers/cpufreq/omap-cpufreq.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 1621208..d8a751f 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -335,9 +335,10 @@ static int __init omap_cpufreq_init(void)
{
if (cpu_is_omap24xx())
mpu_clk_name = virt_prcm_set;
- else if (cpu_is_omap34xx())
+ else if (cpu_is_omap34xx()) {
mpu_clk_name = dpll1_ck;
- else if (cpu_is_omap44xx())
+ iva_clk_name = dpll2_ck;
+ } else if (cpu_is_omap44xx())
mpu_clk_name = dpll_mpu_ck;
if (!mpu_clk_name) {
--
1.7.6.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
[PATCH 3/4] cpufreq: OMAP: ensure the iva coprocessor is at the same opp as the mpu
Signed-off-by: Joshua Emele jem...@gmail.com
---
drivers/cpufreq/omap-cpufreq.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index d8a751f..e8bcad8 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -220,6 +220,9 @@ static inline void clk_free(void)
static int __cpuinit omap_iva_init(struct cpufreq_policy *policy)
{
int result;
+ unsigned long iva_rate;
+ unsigned int opp_index, mpu_freq = omap_getspeed(policy-cpu);
+
if (!iva_clk_name) {
pr_info(%s: iva unavailable\n, __func__);
return 0;
@@ -241,6 +244,21 @@ static int __cpuinit omap_iva_init(struct cpufreq_policy
*policy)
__func__, policy-cpu, result);
return result;
}
+ result = cpufreq_frequency_table_target(policy, freq_table, mpu_freq,
+ CPUFREQ_RELATION_L, opp_index);
+ if (result) {
+ dev_err(mpu_dev, %s: cpu%d: no freq match for %u[%d]\n,
+ __func__, policy-cpu, mpu_freq, result);
+ return result;
+ }
+ iva_rate = iva_freq_table[opp_index].frequency * 1000;
+ result = clk_set_rate(iva_clk, iva_rate);
+ if (result) {
+ pr_err(%s: cpu%d: failed to set %s rate %lu[%d]\n,
+ __func__, policy-cpu, iva_clk-name, iva_rate,
+ result);
+ return result;
+ }
return 0;
}
--
1.7.6.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
[PATCH 4/4] cpufreq: OMAP: scale the iva coprocessor if available
Signed-off-by: Joshua Emele jem...@gmail.com
---
drivers/cpufreq/omap-cpufreq.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index e8bcad8..103fa8b 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -79,7 +79,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
- unsigned int i;
+ unsigned int i, opp_index;
int r, ret = 0;
struct cpufreq_freqs freqs;
struct opp *opp;
@@ -92,13 +92,13 @@ static int omap_target(struct cpufreq_policy *policy,
}
ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
- relation, i);
+ relation, opp_index);
if (ret) {
dev_dbg(mpu_dev, %s: cpu%d: no freq match for %d(ret=%d)\n,
__func__, policy-cpu, target_freq, ret);
return ret;
}
- freqs.new = freq_table[i].frequency;
+ freqs.new = freq_table[opp_index].frequency;
if (!freqs.new) {
dev_err(mpu_dev, %s: cpu%d: no match for freq %d\n, __func__,
policy-cpu, target_freq);
@@ -161,6 +161,17 @@ static int omap_target(struct cpufreq_policy *policy,
}
freqs.new = omap_getspeed(policy-cpu);
+
+ if (!ret iva_freq_table iva_clk) {
+ const unsigned long iva_rate =
+ iva_freq_table[opp_index].frequency * 1000;
+ ret = clk_set_rate(iva_clk, iva_rate);
+ if (ret) {
+ pr_err(%s: failed to set %s rate %lu[%d]\n,
+ __func__, iva_clk-name, iva_rate, ret);
+ }
+ }
+
#ifdef CONFIG_SMP
/*
* Note that loops_per_jiffy is not updated on SMP systems in
--
1.7.6.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: OMAP: second set of PRCM cleanups for 3.8
On Tue, 6 Nov 2012, Tony Lindgren wrote: ..now wondering which configs do not build for you at 7fc54fd3? It builds at least all my test configs. Well at least the ones I have recovered after accidentally deleting some files yesterday, did not have a back up copy of two of them. However if I pull your branch in, build breaks for me for with the rmk-omap3430-ldp-noconfig and rmk-omap4430-sdp-noconfig: arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x48): undefined reference to `omap44xx_restart' They all build successfully here. Here are the rmk config results: rmk-omap3430-ldp: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap3430_ldp_oldconfig/ rmk-omap4430-sdp: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap4430_sdp_oldconfig/ Maybe the versions of the rmk configs you're using are different than mine? The ones here were updated during the v3.6 - v3.7-rc1 transition. You can find mine at: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap3430_ldp_oldconfig/rmk_omap3430_ldp_oldconfig http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap4430_sdp_oldconfig/rmk_omap4430_sdp_oldconfig - Paul -- 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: OMAP: second set of PRCM cleanups for 3.8
* Paul Walmsley p...@pwsan.com [121106 17:54]: On Tue, 6 Nov 2012, Tony Lindgren wrote: ..now wondering which configs do not build for you at 7fc54fd3? It builds at least all my test configs. Well at least the ones I have recovered after accidentally deleting some files yesterday, did not have a back up copy of two of them. The build errors you are talking about are the ones I already pulled into one of the cleanup branches, right? If so, that's fine. However if I pull your branch in, build breaks for me for with the rmk-omap3430-ldp-noconfig and rmk-omap4430-sdp-noconfig: arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x48): undefined reference to `omap44xx_restart' They all build successfully here. Here are the rmk config results: rmk-omap3430-ldp: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap3430_ldp_oldconfig/ rmk-omap4430-sdp: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap4430_sdp_oldconfig/ Maybe the versions of the rmk configs you're using are different than mine? The ones here were updated during the v3.6 - v3.7-rc1 transition. You can find mine at: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap3430_ldp_oldconfig/rmk_omap3430_ldp_oldconfig http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap4430_sdp_oldconfig/rmk_omap4430_sdp_oldconfig I'm getting errors with the allnoconfig ones, there are total four omap defconfigs there not counting the randconfigs. 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: [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
On Tue, 6 Nov 2012, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [121106 17:54]: On Tue, 6 Nov 2012, Tony Lindgren wrote: ..now wondering which configs do not build for you at 7fc54fd3? It builds at least all my test configs. Well at least the ones I have recovered after accidentally deleting some files yesterday, did not have a back up copy of two of them. The build errors you are talking about are the ones I already pulled into one of the cleanup branches, right? If so, that's fine. The build logs I sent were for the ARM: OMAP: second set of PRCM cleanups for 3.8 branch. The last commit in that branch is f17d60d20eb8e679cdd1e9d507394237e58ce0d8 and it is based on 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33. That one builds cleanly. If you're asking for a test build of the base commit, 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33, I just kicked off a test build of that; will post when done. Maybe the versions of the rmk configs you're using are different than mine? The ones here were updated during the v3.6 - v3.7-rc1 transition. You can find mine at: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap3430_ldp_oldconfig/rmk_omap3430_ldp_oldconfig http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/build/rmk_omap4430_sdp_oldconfig/rmk_omap4430_sdp_oldconfig I'm getting errors with the allnoconfig ones, there are total four omap defconfigs there not counting the randconfigs. That might indeed explain the discrepancy; so far only have been building his oldconfig seeds here. Will add his allnoconfig seeds and test again. - Paul -- 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] OMAPDSS: HDMI: Remove __exit macro from hdmi_uninit_display
This function is now used in the driver init path to handle
probe errors properly. Thus, it may be possible to use this function
outside the exit path.
Reported-by: Fengguang Wu fengguang...@intel.com
Reported-by: Yuanhan Liu yuanhan@linux.intel.com
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 0c2f35b..6cf2fe2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -365,7 +365,7 @@ static int __init hdmi_init_display(struct omap_dss_device
*dssdev)
return 0;
}
-static void __exit hdmi_uninit_display(struct omap_dss_device *dssdev)
+static void hdmi_uninit_display(struct omap_dss_device *dssdev)
{
DSSDBG(uninit_display\n);
--
1.7.5.4
--
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 v3 2/7] ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module
From: Mark A. Greer mgr...@animalcreek.com
The current OMAP2 SHAM support doesn't enable DMA
so add that support so it can use DMA just like OMAP3.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index bb314c5..4b4fd5f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
@@ -405,5 +405,5 @@ struct omap_hwmod_ocp_if omap2xxx_l4_core__sham = {
.slave = omap2xxx_sham_hwmod,
.clk= sha_ick,
.addr = omap2xxx_sham_addrs,
- .user = OCP_USER_MPU,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index a041670..703b269 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -873,9 +873,15 @@ struct omap_hwmod_irq_info omap2_sham_mpu_irqs[] = {
{ .irq = -1 }
};
+struct omap_hwmod_dma_info omap2_sham_sdma_chs[] = {
+ { .name = rx, .dma_req = OMAP24XX_DMA_SHA1MD5_RX },
+ { .dma_req = -1 }
+};
+
struct omap_hwmod omap2xxx_sham_hwmod = {
.name = sham,
.mpu_irqs = omap2_sham_mpu_irqs,
+ .sdma_reqs = omap2_sham_sdma_chs,
.main_clk = l4_ck,
.prcm = {
.omap2 = {
--
1.7.12
--
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 v3 3/7] ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Mark A. Greer mgr...@animalcreek.com
Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
from explicit platform_data to hwmod.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 1 +
arch/arm/mach-omap2/devices.c | 42 ++---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 60 ++
3 files changed, 64 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 1f42c9d..6f14d9b 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3342,6 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
CLK(omap-sham,ick, sha12_ick, CK_34XX | CK_36XX),
+ CLK(NULL, sha12_ick,sha12_ick, CK_34XX | CK_36XX),
CLK(NULL, des2_ick, des2_ick, CK_34XX | CK_36XX),
CLK(omap_hsmmc.1, ick, mmchs2_ick,CK_3XXX),
CLK(omap_hsmmc.0, ick, mmchs1_ick,CK_3XXX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index f18fa50..f38ac9d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -36,6 +36,7 @@
#include devices.h
#include cm2xxx_3xxx.h
#include cm-regbits-24xx.h
+#include cm-regbits-34xx.h
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
@@ -453,38 +454,9 @@ static void omap_init_rng(void)
WARN(IS_ERR(pdev), Can't build omap_device for omap_rng\n);
}
-#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_sham_resources[] = {
- {
- .start = OMAP34XX_SEC_SHA1MD5_BASE,
- .end= OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = 49 + OMAP_INTC_START,
- .flags = IORESOURCE_IRQ,
- },
- {
- .start = OMAP34XX_DMA_SHA1MD5_RX,
- .flags = IORESOURCE_DMA,
- }
-};
-static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
-#else
-#define omap3_sham_resources NULL
-#define omap3_sham_resources_sz0
-#endif
-
-static struct platform_device sham_device = {
- .name = omap-sham,
- .id = -1,
-};
-
-static void omap_init_sham(void)
+static void __init omap_init_sham(void)
{
- if (cpu_is_omap24xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -495,18 +467,10 @@ static void omap_init_sham(void)
pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
0, 0);
WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
- } else if (cpu_is_omap34xx()) {
- sham_device.resource = omap3_sham_resources;
- sham_device.num_resources = omap3_sham_resources_sz;
- platform_device_register(sham_device);
} else {
pr_err(%s: platform not supported\n, __func__);
- return;
}
}
-#else
-static inline void omap_init_sham(void) { }
-#endif
#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..785a0c5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3543,6 +3543,65 @@ static struct omap_hwmod_ocp_if omap3xxx_l3_main__gpmc =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_core - SHAM2 (SHA1/MD5) (similar to omap24xx) */
+static struct omap_hwmod_class_sysconfig omap3_sham_sysc = {
+ .rev_offs = 0x5c,
+ .sysc_offs = 0x60,
+ .syss_offs = 0x64,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_sham_class = {
+ .name = sham,
+ .sysc = omap3_sham_sysc,
+};
+
+struct omap_hwmod_irq_info omap3_sham_mpu_irqs[] = {
+ { .irq = 49 + OMAP_INTC_START, },
+ { .irq = -1 }
+};
+
+struct omap_hwmod_dma_info omap3_sham_sdma_reqs[] = {
+ { .name = rx, .dma_req = OMAP34XX_DMA_SHA1MD5_RX, },
+ { .dma_req = -1 }
+};
+
+struct omap_hwmod omap3xxx_sham_hwmod = {
+ .name = sham,
+ .mpu_irqs = omap3_sham_mpu_irqs,
+ .sdma_reqs = omap3_sham_sdma_reqs,
+ .main_clk = sha12_ick,
+ .prcm = {
+
[PATCH v3 0/7] crypto: omap-sham updates
From: Mark A. Greer mgr...@animalcreek.com Changes since v2: - Reworked pm_runtime calls to match where original clk_* calls were so provide better PM (as per Kevin Hilman's comments). Changes since v1: - Removed the check of CM_IDLEST to see if the module exists and instead add the hwmod data for all omap2's and omap3 GP's. - Placed new sha_ick clk entries after the 'omap-sham' entry in the clockxxx_data.c files - Removed cpu_is_xxx() checks in arch/arm/mach-omap2/devices.c:omap_init_sham() - Rebased on the latest k.o. kernel This series updates the crypto omap-sham driver and supporting infrastructure. Notes: a) Based on v3.7-rc4 b) Since these patches will likely go though the OMAP tree (and not through the crypto tree), it would be nice if the crypto guy(s) would ACK or NACK patches 5-7 which modify the drivers/crypto/omap-sham.c driver. c) These have only been tested on an omap2420 h4 and an am37x evm. If you have different hardware available and a few minutes, please test them. A quick and easy test is to enable tcrypt as a module (CONFIG_CRYPTO_TEST=m), boot, then run 'modprobe tcrypt sec=2 mode=403'. 'CONFIG_CRYPTO_SHA1' and 'CONFIG_CRYPTO_DEV_OMAP_SHAM' also have to be enabled. A quick 'grep omap-sham /proc/interrupts' will tell you if the omap-sham driver was really used. d) To test these patches, you will likely need... i) The patch included here: http://marc.info/?l=kernel-janitorsm=134910841909057w=2 ii) This patch from linux-omap/master: 27615a9 (ARM: OMAP: Trivial driver changes to remove include plat/cpu.h) iii) This patch from Paul Walmsley: http://www.spinics.net/lists/linux-omap/msg79436.html e) If you prefer, a version you can test is available at g...@github.com:mgreeraz/linux-mag.git wip/crypto/sham-v3+test f) There is a reduction in DMA performance after switching to dmaengine (see http://www.spinics.net/lists/linux-omap/msg79855.html) g) Many thanks to Jon Hunter for testing on his omap2420 h4. Mark A. Greer (7): ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no SHA IP is present crypto: omap-sham: Convert to use pm_runtime API crypto: omap-sham: Add code to use dmaengine API crypto: omap_sham: Remove usage of private DMA API arch/arm/mach-omap2/clock2430_data.c | 1 + arch/arm/mach-omap2/clock3xxx_data.c | 1 + arch/arm/mach-omap2/devices.c | 73 ++-- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 43 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 60 +++ arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + drivers/crypto/omap-sham.c | 195 +++-- 10 files changed, 245 insertions(+), 150 deletions(-) -- 1.7.12 -- 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 v3 4/7] ARM: OMAP2+: Remove unnecessary message when no SHA IP is present
From: Mark A. Greer mgr...@animalcreek.com
Remove the error message that prints when there is no SHA IP
present to make it consistent with all the other IPs.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/devices.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index f38ac9d..f41c793 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -456,20 +456,15 @@ static void omap_init_rng(void)
static void __init omap_init_sham(void)
{
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- struct omap_hwmod *oh;
- struct platform_device *pdev;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
- oh = omap_hwmod_lookup(sham);
- if (!oh)
- return;
+ oh = omap_hwmod_lookup(sham);
+ if (!oh)
+ return;
- pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
-0, 0);
- WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
- } else {
- pr_err(%s: platform not supported\n, __func__);
- }
+ pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
}
#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
--
1.7.12
--
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 v3 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Mark A. Greer mgr...@animalcreek.com
Convert the device data for the OMAP2 SHAM crypto IP from
explicit platform_data to hwmod.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clock2430_data.c | 1 +
arch/arm/mach-omap2/devices.c | 34
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 +
.../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 37 ++
arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 ++
7 files changed, 73 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 22404fe..4d52ec6 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1993,6 +1993,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, sdrc_ick, sdrc_ick, CK_243X),
CLK(NULL, des_ick, des_ick, CK_243X),
CLK(omap-sham,ick, sha_ick, CK_243X),
+ CLK(NULL, sha_ick, sha_ick, CK_242X),
CLK(omap_rng, ick, rng_ick, CK_243X),
CLK(NULL, rng_ick, rng_ick, CK_243X),
CLK(omap-aes, ick, aes_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index cba60e0..f18fa50 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -34,6 +34,8 @@
#include mux.h
#include control.h
#include devices.h
+#include cm2xxx_3xxx.h
+#include cm-regbits-24xx.h
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
@@ -453,24 +455,6 @@ static void omap_init_rng(void)
#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_sham_resources[] = {
- {
- .start = OMAP24XX_SEC_SHA1MD5_BASE,
- .end= OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = 51 + OMAP_INTC_START,
- .flags = IORESOURCE_IRQ,
- }
-};
-static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
-#else
-#define omap2_sham_resources NULL
-#define omap2_sham_resources_sz0
-#endif
-
#ifdef CONFIG_ARCH_OMAP3
static struct resource omap3_sham_resources[] = {
{
@@ -501,16 +485,24 @@ static struct platform_device sham_device = {
static void omap_init_sham(void)
{
if (cpu_is_omap24xx()) {
- sham_device.resource = omap2_sham_resources;
- sham_device.num_resources = omap2_sham_resources_sz;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+
+ oh = omap_hwmod_lookup(sham);
+ if (!oh)
+ return;
+
+ pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
+0, 0);
+ WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
} else if (cpu_is_omap34xx()) {
sham_device.resource = omap3_sham_resources;
sham_device.num_resources = omap3_sham_resources_sz;
+ platform_device_register(sham_device);
} else {
pr_err(%s: platform not supported\n, __func__);
return;
}
- platform_device_register(sham_device);
}
#else
static inline void omap_init_sham(void) { }
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b5db600..b102a53 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -603,6 +603,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__mcbsp2,
omap2420_l4_core__msdi1,
omap2xxx_l4_core__rng,
+ omap2xxx_l4_core__sham,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
omap2420_l3__gpmc,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c455e41..b1ce7b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -963,6 +963,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
omap2430_l4_core__mcbsp5,
omap2430_l4_core__hdq1w,
omap2xxx_l4_core__rng,
+ omap2xxx_l4_core__sham,
omap2430_l4_wkup__counter_32k,
omap2430_l3__gpmc,
NULL,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index 1a1287d..bb314c5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++
[PATCH v3 7/7] crypto: omap_sham: Remove usage of private DMA API
From: Mark A. Greer mgr...@animalcreek.com
Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 117 -
1 file changed, 117 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b57277c..ebb5255 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -13,8 +13,6 @@
* Some ideas are from old omap-sha1-md5.c driver.
*/
-#define OMAP_SHAM_DMA_PRIVATE
-
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -29,10 +27,8 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
-#ifndef OMAP_SHAM_DMA_PRIVATE
#include linux/dmaengine.h
#include linux/omap-dma.h
-#endif
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
@@ -43,12 +39,6 @@
#include crypto/hash.h
#include crypto/internal/hash.h
-#ifdef OMAP_SHAM_DMA_PRIVATE
-#include plat/cpu.h
-#include plat/dma.h
-#include mach/irqs.h
-#endif
-
#define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
#define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
@@ -120,9 +110,7 @@ struct omap_sham_reqctx {
/* walk state */
struct scatterlist *sg;
-#ifndef OMAP_SHAM_DMA_PRIVATE
struct scatterlist sgl;
-#endif
unsigned intoffset; /* offset in current sg */
unsigned inttotal; /* total request */
@@ -156,12 +144,7 @@ struct omap_sham_dev {
int irq;
spinlock_t lock;
int err;
-#ifdef OMAP_SHAM_DMA_PRIVATE
- int dma;
- int dma_lch;
-#else
struct dma_chan *dma_lch;
-#endif
struct tasklet_struct done_task;
unsigned long flags;
@@ -331,7 +314,6 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd,
const u8 *buf,
return -EINPROGRESS;
}
-#ifndef OMAP_SHAM_DMA_PRIVATE
static void omap_sham_dma_callback(void *param)
{
struct omap_sham_dev *dd = param;
@@ -339,34 +321,18 @@ static void omap_sham_dma_callback(void *param)
set_bit(FLAGS_DMA_READY, dd-flags);
tasklet_schedule(dd-done_task);
}
-#endif
static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
size_t length, int final, int is_sg)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- int len32;
-#else
struct dma_async_tx_descriptor *tx;
struct dma_slave_config cfg;
int ret;
-#endif
dev_dbg(dd-dev, xmit_dma: digcnt: %d, length: %d, final: %d\n,
ctx-digcnt, length, final);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- len32 = DIV_ROUND_UP(length, sizeof(u32));
-
- omap_set_dma_transfer_params(dd-dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
- 1, OMAP_DMA_SYNC_PACKET, dd-dma,
- OMAP_DMA_DST_SYNC_PREFETCH);
-
- omap_set_dma_src_params(dd-dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
- dma_addr, 0, 0);
-
-#else
memset(cfg, 0, sizeof(cfg));
cfg.dst_addr = dd-phys_base + SHA_REG_DIN(0);
@@ -406,7 +372,6 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
tx-callback = omap_sham_dma_callback;
tx-callback_param = dd;
-#endif
omap_sham_write_ctrl(dd, length, final, 1);
@@ -417,12 +382,8 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
set_bit(FLAGS_DMA_ACTIVE, dd-flags);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- omap_start_dma(dd-dma_lch);
-#else
dmaengine_submit(tx);
dma_async_issue_pending(dd-dma_lch);
-#endif
return -EINPROGRESS;
}
@@ -528,7 +489,6 @@ static int omap_sham_update_dma_start(struct omap_sham_dev
*dd)
if (ctx-bufcnt || ctx-offset)
return omap_sham_update_dma_slow(dd);
-#ifndef OMAP_SHAM_DMA_PRIVATE
/*
* Don't use the sg interface when the transfer size is less
* than the number of elements in a DMA frame. Otherwise,
@@ -537,7 +497,6 @@ static int omap_sham_update_dma_start(struct omap_sham_dev
*dd)
*/
if (ctx-total (DST_MAXBURST * sizeof(u32)))
return omap_sham_update_dma_slow(dd);
-#endif
dev_dbg(dd-dev, fast: digcnt: %d, bufcnt: %u, total: %u\n,
ctx-digcnt, ctx-bufcnt, ctx-total);
@@ -599,11 +558,7 @@ static int omap_sham_update_dma_stop(struct omap_sham_dev
*dd)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- omap_stop_dma(dd-dma_lch);
-#else
[PATCH v3 5/7] crypto: omap-sham: Convert to use pm_runtime API
From: Mark A. Greer mgr...@animalcreek.com
Convert the omap-sham crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Paul Walmsley p...@pwsan.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a3fd6fc..85d43b2 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -22,12 +22,12 @@
#include linux/errno.h
#include linux/interrupt.h
#include linux/kernel.h
-#include linux/clk.h
#include linux/irq.h
#include linux/io.h
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
#include linux/cryptohash.h
@@ -141,7 +141,6 @@ struct omap_sham_dev {
struct device *dev;
void __iomem*io_base;
int irq;
- struct clk *iclk;
spinlock_t lock;
int err;
int dma;
@@ -238,7 +237,7 @@ static void omap_sham_copy_ready_hash(struct ahash_request
*req)
static int omap_sham_hw_init(struct omap_sham_dev *dd)
{
- clk_enable(dd-iclk);
+ pm_runtime_get_sync(dd-dev);
if (!test_bit(FLAGS_INIT, dd-flags)) {
omap_sham_write_mask(dd, SHA_REG_MASK,
@@ -653,7 +652,8 @@ static void omap_sham_finish_req(struct ahash_request *req,
int err)
/* atomic operation is not needed here */
dd-flags = ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(dd-dev);
if (req-base.complete)
req-base.complete(req-base, err);
@@ -1198,14 +1198,6 @@ static int __devinit omap_sham_probe(struct
platform_device *pdev)
if (err)
goto dma_err;
- /* Initializing the clock */
- dd-iclk = clk_get(dev, ick);
- if (IS_ERR(dd-iclk)) {
- dev_err(dev, clock intialization failed.\n);
- err = PTR_ERR(dd-iclk);
- goto clk_err;
- }
-
dd-io_base = ioremap(dd-phys_base, SZ_4K);
if (!dd-io_base) {
dev_err(dev, can't ioremap\n);
@@ -1213,11 +1205,14 @@ static int __devinit omap_sham_probe(struct
platform_device *pdev)
goto io_err;
}
- clk_enable(dd-iclk);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
dev_info(dev, hw accel on OMAP rev %u.%u\n,
(omap_sham_read(dd, SHA_REG_REV) SHA_REG_REV_MAJOR) 4,
omap_sham_read(dd, SHA_REG_REV) SHA_REG_REV_MINOR);
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(pdev-dev);
spin_lock(sham.lock);
list_add_tail(dd-list, sham.dev_list);
@@ -1235,9 +1230,8 @@ err_algs:
for (j = 0; j i; j++)
crypto_unregister_ahash(algs[j]);
iounmap(dd-io_base);
+ pm_runtime_disable(dev);
io_err:
- clk_put(dd-iclk);
-clk_err:
omap_sham_dma_cleanup(dd);
dma_err:
if (dd-irq = 0)
@@ -1266,7 +1260,7 @@ static int __devexit omap_sham_remove(struct
platform_device *pdev)
crypto_unregister_ahash(algs[i]);
tasklet_kill(dd-done_task);
iounmap(dd-io_base);
- clk_put(dd-iclk);
+ pm_runtime_disable(pdev-dev);
omap_sham_dma_cleanup(dd);
if (dd-irq = 0)
free_irq(dd-irq, dd);
--
1.7.12
--
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 v3 6/7] crypto: omap-sham: Add code to use dmaengine API
From: Mark A. Greer mgr...@animalcreek.com
Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API. The API to use is chosen by
defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 150 +++--
1 file changed, 145 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 85d43b2..b57277c 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -13,6 +13,8 @@
* Some ideas are from old omap-sha1-md5.c driver.
*/
+#define OMAP_SHAM_DMA_PRIVATE
+
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -27,6 +29,10 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#ifndef OMAP_SHAM_DMA_PRIVATE
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#endif
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
@@ -37,9 +43,11 @@
#include crypto/hash.h
#include crypto/internal/hash.h
+#ifdef OMAP_SHAM_DMA_PRIVATE
#include plat/cpu.h
#include plat/dma.h
#include mach/irqs.h
+#endif
#define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
#define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
@@ -47,6 +55,8 @@
#define SHA1_MD5_BLOCK_SIZESHA1_BLOCK_SIZE
#define MD5_DIGEST_SIZE16
+#defineDST_MAXBURST16 /* Really element number
(en) */
+
#define SHA_REG_DIGCNT 0x14
#define SHA_REG_CTRL 0x18
@@ -110,6 +120,9 @@ struct omap_sham_reqctx {
/* walk state */
struct scatterlist *sg;
+#ifndef OMAP_SHAM_DMA_PRIVATE
+ struct scatterlist sgl;
+#endif
unsigned intoffset; /* offset in current sg */
unsigned inttotal; /* total request */
@@ -143,8 +156,12 @@ struct omap_sham_dev {
int irq;
spinlock_t lock;
int err;
+#ifdef OMAP_SHAM_DMA_PRIVATE
int dma;
int dma_lch;
+#else
+ struct dma_chan *dma_lch;
+#endif
struct tasklet_struct done_task;
unsigned long flags;
@@ -314,15 +331,32 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd,
const u8 *buf,
return -EINPROGRESS;
}
+#ifndef OMAP_SHAM_DMA_PRIVATE
+static void omap_sham_dma_callback(void *param)
+{
+ struct omap_sham_dev *dd = param;
+
+ set_bit(FLAGS_DMA_READY, dd-flags);
+ tasklet_schedule(dd-done_task);
+}
+#endif
+
static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
- size_t length, int final)
+ size_t length, int final, int is_sg)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
+#ifdef OMAP_SHAM_DMA_PRIVATE
int len32;
+#else
+ struct dma_async_tx_descriptor *tx;
+ struct dma_slave_config cfg;
+ int ret;
+#endif
dev_dbg(dd-dev, xmit_dma: digcnt: %d, length: %d, final: %d\n,
ctx-digcnt, length, final);
+#ifdef OMAP_SHAM_DMA_PRIVATE
len32 = DIV_ROUND_UP(length, sizeof(u32));
omap_set_dma_transfer_params(dd-dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
@@ -332,6 +366,48 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
omap_set_dma_src_params(dd-dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
dma_addr, 0, 0);
+#else
+ memset(cfg, 0, sizeof(cfg));
+
+ cfg.dst_addr = dd-phys_base + SHA_REG_DIN(0);
+ cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.dst_maxburst = DST_MAXBURST;
+
+ ret = dmaengine_slave_config(dd-dma_lch, cfg);
+ if (ret) {
+ pr_err(omap-sham: can't configure dmaengine slave: %d\n, ret);
+ return ret;
+ }
+
+ if (is_sg) {
+ /*
+* The SG entry passed in may not have the 'length' member
+* set correctly so use a local SG entry (sgl) with the
+* proper value for 'length' instead. If this is not done,
+* the dmaengine may try to DMA the incorrect amount of data.
+*/
+ sg_init_table(ctx-sgl, 1);
+ ctx-sgl.page_link = ctx-sg-page_link;
+ ctx-sgl.offset = ctx-sg-offset;
+ sg_dma_len(ctx-sgl) = length;
+ sg_dma_address(ctx-sgl) = sg_dma_address(ctx-sg);
+
+ tx = dmaengine_prep_slave_sg(dd-dma_lch, ctx-sgl, 1,
+ DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ } else {
+ tx =
Re: OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups
Hi Kevin, In the latest, pad mux and clocks for all non-essential modules at U-BOOT were removed. This might also cause the problem. We can bring this back in u-boot by adding the following macros and check if it works fine again. include/configs/omap4_common.h -- #define CONFIG_SYS_ENABLE_PADS_ALL #define CONFIG_SYS_CLOCKS_ENABLE_ALL Regards, Sricharan On Wednesday 07 November 2012 06:23 AM, Santosh Shilimkar wrote: + Sricharan, On Tuesday 06 November 2012 06:46 PM, Kevin Hilman wrote: Hello, I just noticed that the kernel wakeup from suspend using RTC is broken after I upgraded u-boot from v2012.04.01 to v2012.10 on my OMAP4430/Panda and OMAP4460/Panda-ES. I haven't isolated the cause yet, but am hoping someone might have a pointer about where to start digging. Kevin -- 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 -- 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] Revert ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
On Tue, Nov 6, 2012 at 10:01 PM, Paul Walmsley p...@pwsan.com wrote: This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc. This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 http://marc.info/?l=linux-arm-kernelm=135067558415214w=2 http://marc.info/?l=linux-arm-kernelm=135216013608196w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernelm=135219411617621w=2 Not a comment however was curious does merging the dependency. make the issue go away? -- 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 0/3] OMAPDSS: DISPC: Writeback fixes
Some issues were found in the DISPC driver when performing scaling with writeback pipeline. This series fixes those issues. Reference tree: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 3.8/writeback_fixes_dispc Archit Taneja (3): OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipeline OMAPDSS: DISPC: Don't allow predecimation for writeback OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for writeback drivers/video/omap2/dss/dispc.c | 39 +++ 1 file changed, 27 insertions(+), 12 deletions(-) -- 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
[PATCH 1/3] OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipeline
dispc_ovl_calc_scaling_44xx() doesn't work correctly for writeback. There are
two issues with it:
- the function tries to calculate pixel clock for the input plane using
dispc_plane_pclk_rate(), calling this with writeback as input plane results in
a BUG(), this function shouldn't be called for writeback at all. Fix this by
calculating pixel clock only when we are not in mem to mem mode.
- the maximum input_width is the product of the downscale ratio supported and
the and the given output_width. This was calculated incorrectly by dividing
output_width with maxdownscale. Fix this.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 05def42..f19cd37 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2264,14 +2264,16 @@ static int dispc_ovl_calc_scaling_44xx(enum omap_plane
plane,
u16 in_height = DIV_ROUND_UP(height, *decim_y);
const int maxsinglelinewidth =
dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
- unsigned long pclk = dispc_plane_pclk_rate(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
- if (mem_to_mem)
- in_width_max = DIV_ROUND_UP(out_width, maxdownscale);
- else
+ if (mem_to_mem) {
+ in_width_max = out_width * maxdownscale;
+ } else {
+ unsigned long pclk = dispc_plane_pclk_rate(plane);
+
in_width_max = dispc_core_clk_rate() /
DIV_ROUND_UP(pclk, out_width);
+ }
*decim_x = DIV_ROUND_UP(width, in_width_max);
--
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
[PATCH 2/3] OMAPDSS: DISPC: Don't allow predecimation for writeback
Since writeback writes to a buffer instead of reading from one, predecimation
doesn't make sense for it. Configure the width and height predecimation limits
to 1 if the plane is writeback.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index f19cd37..664ac6f 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2315,9 +2315,14 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if ((caps OMAP_DSS_OVL_CAP_SCALE) == 0)
return -EINVAL;
- *x_predecim = max_decim_limit;
- *y_predecim = (rotation_type == OMAP_DSS_ROT_TILER
- dss_has_feature(FEAT_BURST_2D)) ? 2 : max_decim_limit;
+ if (plane == OMAP_DSS_WB) {
+ *x_predecim = *y_predecim = 1;
+ } else {
+ *x_predecim = max_decim_limit;
+ *y_predecim = (rotation_type == OMAP_DSS_ROT_TILER
+ dss_has_feature(FEAT_BURST_2D)) ?
+ 2 : max_decim_limit;
+ }
if (color_mode == OMAP_DSS_COLOR_CLUT1 ||
color_mode == OMAP_DSS_COLOR_CLUT2 ||
--
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
[PATCH 3/3] OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for writeback
When calculating row and pixel increments for graphics and video pipes, we need
to consider the dimensions of the input frame to know how to read from the
buffer. Hence, we need to calculate these parameters from the input to the
pipeline.
For writeback, the row and pixel increments need to be calculated based on the
output of the writeback pipeline, i.e, the dimensions of the frame after
scaling. Ensure that dispc driver uses values of out_width and out_height when
calling calc_dma/calc_tiler_rotation_offset.
For graphics and video pipes, the original code passed the original height as
frame_height to calc_dma_rotation_offset, and not the predecimated height. This
is left as it is for now. We need to figure out why pre decimated height isn't
needed.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 664ac6f..db14f20 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2381,7 +2381,7 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
unsigned offset0, offset1;
s32 row_inc;
s32 pix_inc;
- u16 frame_height = height;
+ u16 frame_width, frame_height;
unsigned int field_offset = 0;
u16 in_height = height;
u16 in_width = width;
@@ -2449,20 +2449,28 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
row_inc = 0;
pix_inc = 0;
+ if (plane == OMAP_DSS_WB) {
+ frame_width = out_width;
+ frame_height = out_height;
+ } else {
+ frame_width = in_width;
+ frame_height = height;
+ }
+
if (rotation_type == OMAP_DSS_ROT_TILER)
- calc_tiler_rotation_offset(screen_width, in_width,
+ calc_tiler_rotation_offset(screen_width, frame_width,
color_mode, fieldmode, field_offset,
offset0, offset1, row_inc, pix_inc,
x_predecim, y_predecim);
else if (rotation_type == OMAP_DSS_ROT_DMA)
- calc_dma_rotation_offset(rotation, mirror,
- screen_width, in_width, frame_height,
+ calc_dma_rotation_offset(rotation, mirror, screen_width,
+ frame_width, frame_height,
color_mode, fieldmode, field_offset,
offset0, offset1, row_inc, pix_inc,
x_predecim, y_predecim);
else
calc_vrfb_rotation_offset(rotation, mirror,
- screen_width, in_width, frame_height,
+ screen_width, frame_width, frame_height,
color_mode, fieldmode, field_offset,
offset0, offset1, row_inc, pix_inc,
x_predecim, y_predecim);
--
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 v2 2/2] mailbox: split internal header from API header
Hi Loic,
On 6 November 2012 06:53, Loic PALLARDY loic.palla...@st.com wrote:
On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
Now internal structures can remain hidden to the user and just API
related functions and defines are made available.
Signed-off-by: Omar Ramirez Lunaomar.l...@linaro.org
---
drivers/mailbox/mailbox.c | 34
drivers/mailbox/mailbox.h | 48
+
include/linux/mailbox.h | 22 +++
I agree with the file split but I think mailbox framework API should be
more generic.
omap_ prefix should not be used. mailbox_ prefix will be better.
Ok.
Message type must be more opened like for example:
struct mailbox_msg {
int size;
unsigned char header;
unsigned char *pdata;
};
We can analyze the requirement for having such structure, presumably
you expect variable size messages, in OMAP case it is a 4 byte value,
but I'm open to change in order to accommodate other users needs.
Cheers,
Omar
--
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] OMAPDSS: HDMI: Remove __exit macro from hdmi_uninit_display
On 2012-11-07 05:37, Ricardo Neri wrote:
This function is now used in the driver init path to handle
probe errors properly. Thus, it may be possible to use this function
outside the exit path.
Reported-by: Fengguang Wu fengguang...@intel.com
Reported-by: Yuanhan Liu yuanhan@linux.intel.com
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 0c2f35b..6cf2fe2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -365,7 +365,7 @@ static int __init hdmi_init_display(struct
omap_dss_device *dssdev)
return 0;
}
-static void __exit hdmi_uninit_display(struct omap_dss_device *dssdev)
+static void hdmi_uninit_display(struct omap_dss_device *dssdev)
{
DSSDBG(uninit_display\n);
Thanks, I'll apply.
Tomi
signature.asc
Description: OpenPGP digital signature
