RE: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Hi, diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index df338cb..958e5d5 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -21,11 +21,8 @@ Optional properties: is wired that way. If not specified, a bus width of 8 is assumed. - - ti,nand-ecc-opt:A string setting the ECC layout to use. One of: - - swSoftware method (default) - hwHardware method - hw-romcodegpmc hamming mode method romcode layout + - ti,nand-ecc-scheme: A string setting the ECC layout to use. One of: + ham1 1-bit Hamming ecc code As has been pointed out, this breaks compatibility which should be avoided unless you know the state of use of this binding. I fail to see the advantage of using scheme over opt. You could simply add ham1 here and maintain compatibility. Instead of removing sw, hw, etc. you can simply deprecate them or decide that the kernel doesn't support those options. Renaming 'ti,nand-ecc-opt' to 'ti,nand-ecc-scheme' was as per earlier comments from Olof. So either way is fine with me. Should I revert it back to 'ti,nand-ecc-opt' ? Also, sw, hw_romcode have been deprecated, they are no longer supported in driver. So shouldn't they be removed from the documentation ? However, since you are willing to break compatibility, then you should the generic NAND binding and use nand-ecc-mode adding the values you need. Documentation/devicetree/bindings/mtd/nand.txt: * MTD generic binding - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: none, soft, hw, hw_syndrome, hw_oob_first, soft_bch. Yes I can use generic 'nand-ecc-mode', But the binding values like soft, hw, soft_bch are too generic to describe the hardware. - BCH ECC scheme can itself be of multiple types, bch4/bch8/bch16 so soft_bch is ambiguous. - Similarly soft and hw do not determine the algorithm used like Hamming or BCH. (a) Should I update the generic binding values (if no one else is using) ? like sw - ham1_sw hw - ham1_hw soft_bch- soft_bch4, soft_bch8 OR (b) Should I add newer ones to it (like ham1, bch4, bch8, bch16) ? keeping the old ones intact. And how should I handle un-supported values, (Is pr_err during kernel probe enough ?). [...] - - elm_id: Specifies elm device node. This is required to support BCH - error correction using ELM module. + - ti,elm-id: Specifies pHandle of the ELM devicetree node. + ELM is an on-chip hardware engine on TI SoC which is used for + locating ECC errors for BCHx algorithms. SoC devices which have + ELM hardware engines should specify this device node in .dtsi + Using ELM for ECC error correction frees some CPU cycles. While yes, this is better name and documentation, I don't know that breaking compatibility is justified. As this is TI specific binding, so manufacturer's name should have been included. But as this was missed while adding this binding, so this should be fixed now. (Olof also recommended the same). AFAIK, For TI's NAND OMAP driver, currently there are not many end-users are using these bindings from mainline DT kernel. So this patch series mainly aims to cleanup NAND driver so that migrate to latest DT based kernel from board-file one is easy. So changes should be acceptable from end-user's point, its only matter of which path to take. Request you to please help me finalize this before I resend next patch series addressing other comments from Brian. Thank You.. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Anyway, at this point I think your patch series should be nearly complete. I made a few comments on your patches, and I'd imagine you only should need one more revision (v7) before I can accept it to the l2-mtd.git tree. Yes surely I will send next version (v7), but it might take few days. As some more feedbacks on [PATCH 1] are pending for final conclusion and this needs to be properly re-tested. And thanks much to you and Olof for the feedbacks. I agree some of Olof's feedbacks on DT bindings gave me new view to look at things, And further simplified the NAND driver code. with regards, pekon -- 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: new binutils needed for arm in 3.12-rc1
Hi Rob,
On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley r...@landley.net wrote:
Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM
or some such provides a complete solution.
Sorry, I didn't have a coffee yet, but which subtility am I missing
that prohibits
you from shipping GPLv3 binaries?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: DSS display-new custom enable/disable hooks
On 25/09/13 19:11, Dr. H. Nikolaus Schaller wrote: Hm. I a not sure if this model is complete if it ends at the physical connector. But that would be a different topic. Yes, we currently model the components that exist on the board. I've toyed with the idea of hotplugging a monitor entity after the connector. There's nothing in the model that would strictly prevent that, but hotplug in general would require more work. Well, I understand it that way: RAM - DISPC - Video Encoder - DAC-Stage (the DAC and an output amplifier within the OMAP chip) - OMAP pins - external amplifier (OPA) - physical Connector - cable - TVset connector - some more processing - panel/screen - Consumer or simplified to the most important parts: DISPC - Video Encoder - DAC-Stage - external amplifier - physical Connector Well, this brings up the question, how small parts is it necessary to split the pipeline. For example, DISPC consists of multiple stages. In theory, we could model all those stages with individual SW entities. In practice, that doesn't really give us anything, they are always one whole entity, DISPC. I think the same applies for VENC. There's no need to separate DAC from VENC, they are always one whole entity (as far as I see). Now, you could argue that DISPC and VENC (and the other DSS components) also form one whole entity, the DSS. But here the difference is that we already have different versions of DSS, that have different components. Some don't have VENC, etc. But in all the different DSS versions, VENC and DAC go together. the external amplifier is something specific to our board so that we have to insert it into the pipeline. As you said above, if it would not have any controls we wouldn't have to care about it. But it needs to be enabled/disabled. Note also that even if there weren't any controls (like gpios), the components usually require power. On one board the power could come from VBAT or some other always on source, but on some other, the regulator needs to be turned on. So even if there are no controls, there could be need for a driver. That said, it feels a bit silly to have a driver, whose only function would be to turn on one regulator... The other controls are: Bypass means to bypass something in the DAC-Stage AC means to modify the DAC-Stage output level. Invert is probably a property of the VENC or could also be part of the DAC stage (I don't know). BTW: I have seen a CAUTION block that describes in the last section how some registers must be set to avoid current leakage. That should be done (if not yet) in the suspend code. Yes, I don't think we manage VENC very well at the moment. VENC outputs a video signal, and obviously any register changes required which affect the signal need to be done directly or indirectly by the VENC driver. If OPA requires an inverted signal, it's between VENC and OPA to handle that. Connector is not involved. So we are not really missing an OPA362 driver but the DAC Stage driver within the DM3730 SoC. As I said, I think we can consider DAC as part of VENC. And I think we are really missing OPA362 driver. OPA requires someone to control the enable GPIO (and maybe the regulators), and OPA driver is the only logical place for those. And a mechanism that enabling/disabling the tv display automatically enables/disables all those stages + including an external OPA362. This raises some questions: So how can such a pipeline be individually set up by platform data? How does enable/disable work along the chain? The pipeline is setup in the board file. Each component is given component specific parameters, and the name of its source component. Enable/disable works backwards. Omapfb (or some other component) calls enable on the last entity in the pipeline (connector in this case). The connector driver in turn calls enable on its source entity, which would be OPA. And so on. The OPA itself then should also participate in suspend/resume. Well, that would be something important for proper power management. Only then we can make sure the OPA is disabled correctly. There isn't really anything to suspend/resume on that level. If the display is enabled, it stays enabled, there's no automatic suspend. If there's a system suspend, omapfb (or similar component) will disable the displays. So it's only about enable/disable on this level. But then I would not call it opa362 driver but external-video-amplifier with an enable-gpio that can be defined in the platform data or -1 if it is not required. In the latter case the driver simply does nothing functional. Well, this is perhaps a bit about semantics, but it is a driver for OPA362 hardware. Sure, we can make a more generic driver if we see that there are other external amps that have very similar controls. But it's still an OPA362 driver, but it would also be OPA123, OPA321, etc. driver. Making it external-video-amplifier driver is probably
Re: [PATCH 2/2] mmc: omap_hsmmc: Enable SDIO interrupt
2013/9/26 Tony Lindgren t...@atomide.com:
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with wl12xx
connected to MMC2 with wl12xx waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
and Andreas Fenkart andreas.fenk...@streamunlimited.com
with the SDIO IRQ handing improved following how sdhci.c
is doing it.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Cc: Andreas Fenkart afenk...@gmail.com
Cc: Balaji T K balaj...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/mmc/host/omap_hsmmc.c | 75
+
1 file changed, 67 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index aa97497..e925c0e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -103,6 +103,7 @@
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -183,6 +184,11 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+
+ int flags;
+#define HSMMC_RUNTIME_SUSPENDED(1 0)/* Runtime suspended
*/
+#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -463,27 +469,34 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, ISE, 0);
OMAP_HSMMC_WRITE(host-base, IE, 0);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
This is wrong. SDIO IRQ must not be disabled upon host initiated transfer.
see omap_hsmmc_request_done
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1040,8 +1053,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
+ if (host-req_in_progress)
+ omap_hsmmc_do_irq(host, status);
+
+ if (status CIRQ_EN)
+ mmc_signal_sdio_irq(host-mmc);
/* Flush posted write */
status = OMAP_HSMMC_READ(host-base, STAT);
@@ -1556,6 +1573,43 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
mmc_slot(host).init_card(card);
}
+static void omap_hsmmc_enable_sdio_irq_nolock(struct omap_hsmmc_host *host,
+int enable)
+{
+
Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once
* Daniel Mack | 2013-09-22 16:50:03 [+0200]:
cdd-cd and cdd-descs_phys are allocated DESCS_AREAS times from
init_descs() and freed as often from purge_descs(). This leads to both
memory leaks and double-frees.
Fix this by pulling the calls to dma_{alloc,free}_coherent() out of the
loops.
While at it, remove the intermediate variable mem_decs (I guess it was
only there to make the code comply to the 80-chars CodingSytle rule).
Signed-off-by: Daniel Mack zon...@gmail.com
Please don't merge the memory descriptors. The idea was initially to
allocate multiple small descriptors instead one big. The descrriptor
turned out to be enough so it looks like the way it looks.
If you want to clean this up, please either remove the for loop and
allocate only one memory area or please prepare for multiple descripors
(I think two is the upper limit).
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
On 25/09/13 14:31, Mark Brown wrote: From: Mark Brown broo...@linaro.org The DSI-CM driver uses the backlight class so needs to build depend on it. Signed-off-by: Mark Brown broo...@linaro.org --- drivers/video/omap2/displays-new/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/omap2/displays-new/Kconfig b/drivers/video/omap2/displays-new/Kconfig index 6c90885..10b25e7 100644 --- a/drivers/video/omap2/displays-new/Kconfig +++ b/drivers/video/omap2/displays-new/Kconfig @@ -35,6 +35,7 @@ config DISPLAY_PANEL_DPI config DISPLAY_PANEL_DSI_CM tristate Generic DSI Command Mode Panel + depends on BACKLIGHT_CLASS_DEVICE help Driver for generic DSI command mode panels. Thanks, I'll queue for 3.12 fixes. I wish we could select instead of depends on... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
On Wed, Sep 25, 2013 at 10:29:03PM +0100, Brian Norris wrote: On Wed, Sep 25, 2013 at 01:33:27PM -0700, Olof Johansson wrote: On Wed, Sep 25, 2013 at 1:05 PM, Brian Norris computersforpe...@gmail.com wrote: Olof has given good advice on your DT binding and has (slowly) been responding to other requests for DT review that make it to his list. I see that he hasn't followed up on your changes (this v6), so pinging him (as you did) is probably the correct approach. But please do recognize that the DT list is very high volume, so it's hard to get good timely responses there. I am not a DT mainainer, but sometimes when I see a binding that appears to be wrong I speak up. In this case, the binding was one of those. Whoops, my bad. I was deceived by the responses I've seen from you on other issues (thanks, BTW). In that case, I haven't seen any response from a proper DT binding maintainer :( Hmm... this is the first email in this thread I've received, and I don't have older postings either. It looks like I must have cocked up subscribing to the devicetree list, but as I was CC'd directly on many patches I hadn't noticed. As far as I can see I wasn't CC'd directly on any version of this series, which would have helped to highlight the series as needing review. Apologies for that. I've attempted to correct the problem. Hopefully I've got this right and mails are not being silently dropped somewhere. Pekon, could you please re-send this version of the patches? Cheers, Mark. So, I have no more objections to it, and I hope you can get a quick review from a DT maintainer on the rest of the binding. At this point, I'm comfortable going ahead without their ack, since they obviously don't care/don't have the manpower to review. Brian -- 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 00/11] ARM: OMAP2+: AM43x PRCM basic support
Hi Paul, Benoit, Tony, This series adds PRCM support (except clock tree) for AM43x SoC's. Current version is based on Rajendra's comments and discussions, please consider this for inclusion in the coming merge window. Major changes compared to v2 (v3 was only an rfc for current approach): 1. omap_hwmod_33xx_43xx_interconnect_data.c has the common interconnect ocp's structs shared between AM335x and AM43x 2. omap_hwmod_33xx_43xx_ipblock_data.c has the common hwmod structs shared between AM335x and AM43x 3. Instances where clock domain or clock topology has changed in the few cases, have separate structures for AM335x and AM43x 4. To handle scenarios where register offsets are different, they are dynamically init-ed in omap_hwmod_33xx_43xx_ipblock_data.c 5. Register offsets for hwmod's that are present either in AM335x or AM43x are updated statically in omap_hwmod_33xx_data.c or omap_hwmod_43xx_data.c as that was cleaner. Major changes compared to rfc v3: 1. All register offsets properly taken care for AM43x (with rfc v3, a couple of issues was detected while testing on pre-silicon) 2. There were two patches for common hwmod data movement (one for interconnect and other for ip block data), both were combined to have a cleaner series that is bisectable. 3. Cleaner seperation of common data This series has been boot tested on pre-silicon platform with the help of Tero's DT clock tree conversion series. This series has been tested on AM335x-EVM too. The change that re-introduces SW_SLEEP for OMAP4 has been left out from this series as it is the only potential change that affect other platforms. It will be taken care seperately. Additional details: AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. As AM43x PRCM register layout differs from AM335x and is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. Currently there is no public TRM available for AM43x. Changes based on: v3.12-rc2 Regards Afzal Afzal Mohammed (7): ARM: OMAP2+: hwmod: AM335x/AM43x: move common data ARM: OMAP2+: hwmod: AM335x: runtime register update ARM: OMAP2+: hwmod: AM335x: remove static register offs ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AM43x support ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 arch/arm/mach-omap2/Makefile |9 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c| 196 ++ arch/arm/mach-omap2/cm33xx.c | 16 +- arch/arm/mach-omap2/cm33xx.h | 12 +- arch/arm/mach-omap2/cminst44xx.c | 29 +- arch/arm/mach-omap2/cminst44xx.h | 26 +- arch/arm/mach-omap2/io.c |6 + arch/arm/mach-omap2/omap_hwmod.c |8 + arch/arm/mach-omap2/omap_hwmod.h |1 + .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 163 ++ .../omap_hwmod_33xx_43xx_interconnect_data.c | 643 +++ .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 1456 +++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1966 +--- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 622 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c| 142 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 18 files changed, 3438 insertions(+), 2003 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 1.8.3.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 01/11] ARM: OMAP2+: CM: cm_inst offset s16-u16
From: Ankur Kishore a-kish...@ti.com
Most of the AM43x CM reg address offsets are with MSB bit '1' (on
16-bit value) leading to arithmetic miscalculations while calculating
CLOCK ENABLE register's address because cm_inst field was a type of
const s16, so make it const u16.
Also modify relevant functions so as to take care of the above.
[af...@ti.com: fixup and cleanup]
Signed-off-by: Ankur Kishore a-kish...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clockdomain.h | 2 +-
arch/arm/mach-omap2/cm33xx.c | 16
arch/arm/mach-omap2/cm33xx.h | 10 +-
arch/arm/mach-omap2/cminst44xx.c | 20 ++--
arch/arm/mach-omap2/cminst44xx.h | 26 +-
5 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 4b03394..5431b0c 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -132,7 +132,7 @@ struct clockdomain {
u8 _flags;
const u8 dep_bit;
const u8 prcm_partition;
- const s16 cm_inst;
+ const u16 cm_inst;
const u16 clkdm_offs;
struct clkdm_dep *wkdep_srcs;
struct clkdm_dep *sleepdep_srcs;
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 325a515..40a22e5 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -48,13 +48,13 @@
/* Private functions */
/* Read a register in a CM instance */
-static inline u32 am33xx_cm_read_reg(s16 inst, u16 idx)
+static inline u32 am33xx_cm_read_reg(u16 inst, u16 idx)
{
return __raw_readl(cm_base + inst + idx);
}
/* Write into a register in a CM */
-static inline void am33xx_cm_write_reg(u32 val, s16 inst, u16 idx)
+static inline void am33xx_cm_write_reg(u32 val, u16 inst, u16 idx)
{
__raw_writel(val, cm_base + inst + idx);
}
@@ -138,7 +138,7 @@ static bool _is_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
* @c must be the unshifted value for CLKTRCTRL - i.e., this function
* will handle the shift itself.
*/
-static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
+static void _clktrctrl_write(u8 c, u16 inst, u16 cdoffs)
{
u32 v;
@@ -158,7 +158,7 @@ static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
* Returns true if the clockdomain referred to by (@inst, @cdoffs)
* is in hardware-supervised idle mode, or 0 otherwise.
*/
-bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
+bool am33xx_cm_is_clkdm_in_hwsup(u16 inst, u16 cdoffs)
{
u32 v;
@@ -177,7 +177,7 @@ bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
* Put a clockdomain referred to by (@inst, @cdoffs) into
* hardware-supervised idle mode. No return value.
*/
-void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_enable_hwsup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_ENABLE_AUTO, inst, cdoffs);
}
@@ -191,7 +191,7 @@ void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
* software-supervised idle mode, i.e., controlled manually by the
* Linux OMAP clockdomain code. No return value.
*/
-void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, inst, cdoffs);
}
@@ -204,7 +204,7 @@ void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
* Put a clockdomain referred to by (@inst, @cdoffs) into idle
* No return value.
*/
-void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, inst, cdoffs);
}
@@ -217,7 +217,7 @@ void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
* Take a clockdomain referred to by (@inst, @cdoffs) out of idle,
* waking it up. No return value.
*/
-void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_WAKEUP, inst, cdoffs);
}
diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h
index 9d1f4fc..757320b 100644
--- a/arch/arm/mach-omap2/cm33xx.h
+++ b/arch/arm/mach-omap2/cm33xx.h
@@ -377,11 +377,11 @@
#ifndef __ASSEMBLER__
-extern bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs);
+bool am33xx_cm_is_clkdm_in_hwsup(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_enable_hwsup(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs);
+void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs);
#if defined(CONFIG_SOC_AM33XX) ||
[PATCH v4 03/11] ARM: OMAP2+: hwmod: AM335x: runtime register update
Most of IP's in AM335x is present on AM43x and so in those cases both
will use same hwmod database (except for a few cases where clock related
details differ), but there is difference w.r.t register offset between
these. Update register offsets at runtime based on the SoC detected to
help in sharing otherwise same hwmod.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 +
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 77 ++
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
3 files changed, 80 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index e873e72..a9a7902 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
@@ -157,4 +157,6 @@ extern struct omap_hwmod_class am33xx_spi_hwmod_class;
extern struct omap_gpio_dev_attr gpio_dev_attr;
extern struct omap2_mcspi_dev_attr mcspi_attrib;
+void omap_hwmod_am33xx_reg(void);
+
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 3e70e9c..da40252 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -24,6 +24,10 @@
#include prm33xx.h
#include omap_hwmod_33xx_43xx_common_data.h
+#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
+#define RSTCTRL(oh, rstctrl) ((oh).prcm.omap4.rstctrl_offs = (rstctrl))
+#define RSTST(oh, rstst) ((oh).prcm.omap4.rstst_offs = (rstst))
+
/*
* 'l3' class
* instance(s): l3_main, l3_s, l3_instr
@@ -1360,3 +1364,76 @@ struct omap_hwmod am33xx_wd_timer1_hwmod = {
},
},
};
+
+static void omap_hwmod_am33xx_clkctrl(void)
+{
+ CLKCTRL(am33xx_uart2_hwmod, AM33XX_CM_PER_UART1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart3_hwmod, AM33XX_CM_PER_UART2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart4_hwmod, AM33XX_CM_PER_UART3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart5_hwmod, AM33XX_CM_PER_UART4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart6_hwmod, AM33XX_CM_PER_UART5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan0_hwmod, AM33XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan1_hwmod, AM33XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_elm_hwmod, AM33XX_CM_PER_ELM_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss0_hwmod, AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss1_hwmod, AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss2_hwmod, AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio1_hwmod, AM33XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio2_hwmod, AM33XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio3_hwmod, AM33XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c2_hwmod, AM33XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c3_hwmod, AM33XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mailbox_hwmod, AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp0_hwmod, AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp1_hwmod, AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc0_hwmod, AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc1_hwmod, AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi0_hwmod, AM33XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi1_hwmod, AM33XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spinlock_hwmod, AM33XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer2_hwmod, AM33XX_CM_PER_TIMER2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer3_hwmod, AM33XX_CM_PER_TIMER3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer4_hwmod, AM33XX_CM_PER_TIMER4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer5_hwmod, AM33XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer6_hwmod, AM33XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer7_hwmod, AM33XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex0_hwmod,
+ AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_smartreflex1_hwmod,
+ AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart1_hwmod, AM33XX_CM_WKUP_UART0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_timer1_hwmod, AM33XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c1_hwmod, AM33XX_CM_WKUP_I2C0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_wd_timer1_hwmod, AM33XX_CM_WKUP_WDT1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_rtc_hwmod, AM33XX_CM_RTC_RTC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc2_hwmod, AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpmc_hwmod, AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_ls_hwmod, AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_l4_wkup_hwmod, AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
+
RE: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Hi Mark, Pekon, could you please re-send this version of the patches? As already there are feedbacks on the patches, so re-sending the Patch series might clutter someone else's mailbox. Will it be possible for you to fetch the patches from MTD archives? else I would send you the patches separately.. I'm attaching the URL from MTD archives for each patch separately, and you can follow that thread to see existing comments. [PATCH v6 0/4] http://lists.infradead.org/pipermail/linux-mtd/2013-September/048613.html [PATCH v6 1/4] http://lists.infradead.org/pipermail/linux-mtd/2013-September/048611.html [PATCH v6 2/4] http://lists.infradead.org/pipermail/linux-mtd/2013-September/048612.html [PATCH v6 3/4] http://lists.infradead.org/pipermail/linux-mtd/2013-September/048615.html [PATCH v6 3/4] http://lists.infradead.org/pipermail/linux-mtd/2013-September/048614.html with regards, pekon -- 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 04/11] ARM: OMAP2+: hwmod: AM335x: remove static register offs
Hwmod common to AM43x and AM335x has register offsets different. It is
now updated based on SoC detection at run time, hence remove statically
initialized ones.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 57 --
1 file changed, 57 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index da40252..598f813 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -44,7 +44,6 @@ struct omap_hwmod am33xx_l3_main_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L3_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -66,7 +65,6 @@ struct omap_hwmod am33xx_l3_instr_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -89,7 +87,6 @@ struct omap_hwmod am33xx_l4_ls_hwmod = {
.main_clk = l4ls_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -103,7 +100,6 @@ struct omap_hwmod am33xx_l4_wkup_hwmod = {
.flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -124,7 +120,6 @@ struct omap_hwmod am33xx_mpu_hwmod = {
.main_clk = dpll_mpu_m2_ck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_MPU_MPU_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -159,8 +154,6 @@ struct omap_hwmod am33xx_pruss_hwmod = {
.main_clk = pruss_ocp_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_PRUSS_CLKCTRL_OFFSET,
- .rstctrl_offs = AM33XX_RM_PER_RSTCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -185,9 +178,6 @@ struct omap_hwmod am33xx_gfx_hwmod = {
.main_clk = gfx_fck_div_ck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
- .rstctrl_offs = AM33XX_RM_GFX_RSTCTRL_OFFSET,
- .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -232,7 +222,6 @@ struct omap_hwmod am33xx_aes0_hwmod = {
.main_clk = aes0_fck,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_AES0_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -258,7 +247,6 @@ struct omap_hwmod am33xx_sha0_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_SHA0_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -277,7 +265,6 @@ struct omap_hwmod am33xx_ocmcram_hwmod = {
.main_clk = l3_gclk,
.prcm = {
.omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -296,7 +283,6 @@ struct omap_hwmod am33xx_smartreflex0_hwmod = {
.main_clk = smartreflex0_fck,
.prcm = {
.omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -310,7 +296,6 @@ struct omap_hwmod am33xx_smartreflex1_hwmod = {
.main_clk = smartreflex1_fck,
.prcm = {
.omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
@@ -352,7 +337,6 @@ struct omap_hwmod am33xx_cpgmac0_hwmod = {
.mpu_rt_idx = 1,
.prcm = {
.omap4 = {
- .clkctrl_offs =
[PATCH v4 05/11] ARM: OMAP2+: PRCM: AM43x definitions
Add AM43x CMINST, CDOFFS, RM_RSTST RM_RSTCTRL definitions - minimal ones that would be used. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/prcm43xx.h | 141 + 1 file changed, 141 insertions(+) create mode 100644 arch/arm/mach-omap2/prcm43xx.h diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h new file mode 100644 index 000..f0636ec --- /dev/null +++ b/arch/arm/mach-omap2/prcm43xx.h @@ -0,0 +1,141 @@ +/* + * AM43x PRCM defines + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H +#define __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H + +#define AM43XX_PRM_PARTITION 1 +#define AM43XX_CM_PARTITION1 + +/* PRM instances */ +#define AM43XX_PRM_OCP_SOCKET_INST 0x +#define AM43XX_PRM_MPU_INST0x0300 +#define AM43XX_PRM_GFX_INST0x0400 +#define AM43XX_PRM_RTC_INST0x0500 +#define AM43XX_PRM_TAMPER_INST 0x0600 +#define AM43XX_PRM_CEFUSE_INST 0x0700 +#define AM43XX_PRM_PER_INST0x0800 +#define AM43XX_PRM_WKUP_INST 0x2000 +#define AM43XX_PRM_DEVICE_INST 0x4000 + +/* RM RSTCTRL offsets */ +#define AM43XX_RM_PER_RSTCTRL_OFFSET 0x0010 +#define AM43XX_RM_GFX_RSTCTRL_OFFSET 0x0010 +#define AM43XX_RM_WKUP_RSTCTRL_OFFSET 0x0010 + +/* RM RSTST offsets */ +#define AM43XX_RM_GFX_RSTST_OFFSET 0x0014 +#define AM43XX_RM_WKUP_RSTST_OFFSET0x0014 + +/* CM instances */ +#define AM43XX_CM_WKUP_INST0x2800 +#define AM43XX_CM_DEVICE_INST 0x4100 +#define AM43XX_CM_DPLL_INST0x4200 +#define AM43XX_CM_MPU_INST 0x8300 +#define AM43XX_CM_GFX_INST 0x8400 +#define AM43XX_CM_RTC_INST 0x8500 +#define AM43XX_CM_TAMPER_INST 0x8600 +#define AM43XX_CM_CEFUSE_INST 0x8700 +#define AM43XX_CM_PER_INST 0x8800 + +/* CD offsets */ +#define AM43XX_CM_WKUP_L3_AON_CDOFFS 0x +#define AM43XX_CM_WKUP_L3S_TSC_CDOFFS 0x0100 +#define AM43XX_CM_WKUP_L4_WKUP_AON_CDOFFS 0x0200 +#define AM43XX_CM_WKUP_WKUP_CDOFFS 0x0300 +#define AM43XX_CM_MPU_MPU_CDOFFS 0x +#define AM43XX_CM_GFX_GFX_L3_CDOFFS0x +#define AM43XX_CM_RTC_RTC_CDOFFS 0x +#define AM43XX_CM_TAMPER_TAMPER_CDOFFS 0x +#define AM43XX_CM_CEFUSE_CEFUSE_CDOFFS 0x +#define AM43XX_CM_PER_L3_CDOFFS0x +#define AM43XX_CM_PER_L3S_CDOFFS 0x0200 +#define AM43XX_CM_PER_ICSS_CDOFFS 0x0300 +#define AM43XX_CM_PER_L4LS_CDOFFS 0x0400 +#define AM43XX_CM_PER_EMIF_CDOFFS 0x0700 +#define AM43XX_CM_PER_DSS_CDOFFS 0x0a00 +#define AM43XX_CM_PER_CPSW_CDOFFS 0x0b00 +#define AM43XX_CM_PER_OCPWP_L3_CDOFFS 0x0c00 + +/* CLK CTRL offsets */ +#define AM43XX_CM_PER_UART1_CLKCTRL_OFFSET 0x0580 +#define AM43XX_CM_PER_UART2_CLKCTRL_OFFSET 0x0588 +#define AM43XX_CM_PER_UART3_CLKCTRL_OFFSET 0x0590 +#define AM43XX_CM_PER_UART4_CLKCTRL_OFFSET 0x0598 +#define AM43XX_CM_PER_UART5_CLKCTRL_OFFSET 0x05a0 +#define AM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET 0x0428 +#define AM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET 0x0430 +#define AM43XX_CM_PER_ELM_CLKCTRL_OFFSET 0x0468 +#define AM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET 0x0438 +#define AM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET 0x0440 +#define AM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET 0x0448 +#define AM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET 0x0478 +#define AM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET 0x0480 +#define AM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET 0x0488 +#define AM43XX_CM_PER_I2C1_CLKCTRL_OFFSET 0x04a8 +#define AM43XX_CM_PER_I2C2_CLKCTRL_OFFSET 0x04b0 +#define AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET 0x04b8 +#define AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET 0x04c0 +#define AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET 0x04c8 +#define AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET 0x0500 +#define AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET
[PATCH v4 07/11] ARM: OMAP2+: CM: AM43x clockdomain data
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
OMAP4 clockdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clockdomain.h | 2 +
arch/arm/mach-omap2/clockdomains43xx_data.c | 196
arch/arm/mach-omap2/cminst44xx.c| 9 ++
3 files changed, 207 insertions(+)
create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 5431b0c..f17f006 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -218,6 +218,7 @@ extern void __init am33xx_clockdomains_init(void);
extern void __init omap44xx_clockdomains_init(void);
extern void __init omap54xx_clockdomains_init(void);
extern void __init dra7xx_clockdomains_init(void);
+void am43xx_clockdomains_init(void);
extern void clkdm_add_autodeps(struct clockdomain *clkdm);
extern void clkdm_del_autodeps(struct clockdomain *clkdm);
@@ -226,6 +227,7 @@ extern struct clkdm_ops omap2_clkdm_operations;
extern struct clkdm_ops omap3_clkdm_operations;
extern struct clkdm_ops omap4_clkdm_operations;
extern struct clkdm_ops am33xx_clkdm_operations;
+extern struct clkdm_ops am43xx_clkdm_operations;
extern struct clkdm_dep gfx_24xx_wkdeps[];
extern struct clkdm_dep dsp_24xx_wkdeps[];
diff --git a/arch/arm/mach-omap2/clockdomains43xx_data.c
b/arch/arm/mach-omap2/clockdomains43xx_data.c
new file mode 100644
index 000..6d71c60
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains43xx_data.c
@@ -0,0 +1,196 @@
+/*
+ * AM43xx Clock domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+
+#include clockdomain.h
+#include prcm44xx.h
+#include prcm43xx.h
+
+static struct clockdomain l4_cefuse_43xx_clkdm = {
+ .name = l4_cefuse_clkdm,
+ .pwrdm= { .name = cefuse_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_CEFUSE_INST,
+ .clkdm_offs = AM43XX_CM_CEFUSE_CEFUSE_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain mpu_43xx_clkdm = {
+ .name = mpu_clkdm,
+ .pwrdm= { .name = mpu_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_MPU_INST,
+ .clkdm_offs = AM43XX_CM_MPU_MPU_CDOFFS,
+ .flags= CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4ls_43xx_clkdm = {
+ .name = l4ls_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_L4LS_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain tamper_43xx_clkdm = {
+ .name = tamper_clkdm,
+ .pwrdm= { .name = tamper_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_TAMPER_INST,
+ .clkdm_offs = AM43XX_CM_TAMPER_TAMPER_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain l4_rtc_43xx_clkdm = {
+ .name = l4_rtc_clkdm,
+ .pwrdm= { .name = rtc_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_RTC_INST,
+ .clkdm_offs = AM43XX_CM_RTC_RTC_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain pruss_ocp_43xx_clkdm = {
+ .name = pruss_ocp_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_ICSS_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain ocpwp_l3_43xx_clkdm = {
+ .name = ocpwp_l3_clkdm,
+ .pwrdm= { .name = per_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_PER_INST,
+ .clkdm_offs = AM43XX_CM_PER_OCPWP_L3_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain l3s_tsc_43xx_clkdm = {
+ .name = l3s_tsc_clkdm,
+ .pwrdm= { .name = wkup_pwrdm },
+ .prcm_partition = AM43XX_CM_PARTITION,
+ .cm_inst = AM43XX_CM_WKUP_INST,
+ .clkdm_offs = AM43XX_CM_WKUP_L3S_TSC_CDOFFS,
+ .flags= CLKDM_CAN_SWSUP,
+};
+
+static struct clockdomain dss_43xx_clkdm = {
+ .name = dss_clkdm,
+ .pwrdm
[PATCH v4 06/11] ARM: OMAP2+: PM: AM43x powerdomain data
From: Ambresh K ambr...@ti.com
Add the data file to describe all power domains in AM43x SoC.
OMAP4 powerdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/powerdomain.h | 1 +
arch/arm/mach-omap2/powerdomains43xx_data.c | 142
2 files changed, 143 insertions(+)
create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index baf3d8b..da5a59a 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -257,6 +257,7 @@ extern void am33xx_powerdomains_init(void);
extern void omap44xx_powerdomains_init(void);
extern void omap54xx_powerdomains_init(void);
extern void dra7xx_powerdomains_init(void);
+void am43xx_powerdomains_init(void);
extern struct pwrdm_ops omap2_pwrdm_operations;
extern struct pwrdm_ops omap3_pwrdm_operations;
diff --git a/arch/arm/mach-omap2/powerdomains43xx_data.c
b/arch/arm/mach-omap2/powerdomains43xx_data.c
new file mode 100644
index 000..febc879
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains43xx_data.c
@@ -0,0 +1,142 @@
+/*
+ * AM43xx Power domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include powerdomain.h
+
+#include prcm-common.h
+#include prcm44xx.h
+#include prcm43xx.h
+
+static struct powerdomain gfx_43xx_pwrdm = {
+ .name = gfx_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_GFX_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_ON,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* gfx_mem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* gfx_mem */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain mpu_43xx_pwrdm = {
+ .name = mpu_pwrdm,
+ .voltdm = { .name = mpu },
+ .prcm_offs= AM43XX_PRM_MPU_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .banks= 3,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* mpu_l1 */
+ [1] = PWRSTS_OFF_RET, /* mpu_l2 */
+ [2] = PWRSTS_OFF_RET, /* mpu_ram */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* mpu_l1 */
+ [1] = PWRSTS_ON,/* mpu_l2 */
+ [2] = PWRSTS_ON,/* mpu_ram */
+ },
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain rtc_43xx_pwrdm = {
+ .name = rtc_pwrdm,
+ .voltdm = { .name = rtc },
+ .prcm_offs= AM43XX_PRM_RTC_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+static struct powerdomain wkup_43xx_pwrdm = {
+ .name = wkup_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_WKUP_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+ .banks= 1,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF, /* debugss_mem */
+ },
+ .pwrsts_mem_on = {
+ [0] = PWRSTS_ON,/* debugss_mem */
+ },
+};
+
+static struct powerdomain tamper_43xx_pwrdm = {
+ .name = tamper_pwrdm,
+ .voltdm = { .name = tamper },
+ .prcm_offs= AM43XX_PRM_TAMPER_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_ON,
+};
+
+static struct powerdomain cefuse_43xx_pwrdm = {
+ .name = cefuse_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_CEFUSE_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_ON,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain per_43xx_pwrdm = {
+ .name = per_pwrdm,
+ .voltdm = { .name = core },
+ .prcm_offs= AM43XX_PRM_PER_INST,
+ .prcm_partition = AM43XX_PRM_PARTITION,
+ .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .banks= 4,
+ .pwrsts_mem_ret = {
+ [0] = PWRSTS_OFF_RET, /* icss_mem */
+ [1] = PWRSTS_OFF_RET, /* per_mem */
+ [2] = PWRSTS_OFF_RET, /* ram1_mem */
+
[PATCH v4 09/11] ARM: OMAP2+: hwmod: AM43x operations
Reuse OMAP4 operations on AM43x.
Context related ops are not used on AM43x, as this would not add value
when using DT and AM43x is DT only boot. This additionally helps not to
add context register offset for each hwmod.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d9ee0ff..aa593da 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4125,6 +4125,14 @@ void __init omap_hwmod_init(void)
soc_ops.init_clkdm = _init_clkdm;
soc_ops.update_context_lost = _omap4_update_context_lost;
soc_ops.get_context_lost = _omap4_get_context_lost;
+ } else if (soc_is_am43xx()) {
+ soc_ops.enable_module = _omap4_enable_module;
+ soc_ops.disable_module = _omap4_disable_module;
+ soc_ops.wait_target_ready = _omap4_wait_target_ready;
+ soc_ops.assert_hardreset = _omap4_assert_hardreset;
+ soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
+ soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
+ soc_ops.init_clkdm = _init_clkdm;
} else if (soc_is_am33xx()) {
soc_ops.enable_module = _am33xx_enable_module;
soc_ops.disable_module = _am33xx_disable_module;
--
1.8.3.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 08/11] ARM: OMAP2+: hwmod: AM43x support
Add hwmod support for IP's that are present in AM43x, but not in AM335x.
AM43x additional ones added here are,
1. synctimer
2. timer8-11
3. ehrpwm3-5
4. spi2-4
5. gpio4-5
AM43x pruss interconnect which is different as compared to AM335x, has
been taken care.
And register offsets for same hwmod's shared with AM335x is different,
AM43x register offsets are updated appropriately.
ocp clock of those in l4_wkup is fed from sys_clkin_ck instead of
dpll_core_m4_div2_ck, so ocpif for those in AM43x l4_wkup has been
added seperately.
hwmod's has been added for those that have main clock (wkup_m3, control,
gpio0) and clock domain (l4_hs) different from AM335x. debugss and
adc_tsc that have different clocks and clockdomains repectively has not
been added due to the reasons mentioned below.
AM43x also has IP's like qspi, hdq1w, vpfe, des, rng, usb, dss, debugss,
adc_tsc. These are not handled here due to both/either of following
reasons,
1. To avoid churn; most of them don't have DT bindings, which would
necessitate adding address space in hwmod, which any way would have
to be removed once DT bindings happen with driver support.
2. patches would come in from sources other than the author
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 1 +
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 1 +
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 74 +++
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 622 +
4 files changed, 698 insertions(+)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_43xx_data.c
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index d02acf9..0f97d63 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -752,6 +752,7 @@ extern int omap44xx_hwmod_init(void);
extern int omap54xx_hwmod_init(void);
extern int am33xx_hwmod_init(void);
extern int dra7xx_hwmod_init(void);
+int am43xx_hwmod_init(void);
extern int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois);
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
index a9a7902..130332c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h
@@ -158,5 +158,6 @@ extern struct omap_gpio_dev_attr gpio_dev_attr;
extern struct omap2_mcspi_dev_attr mcspi_attrib;
void omap_hwmod_am33xx_reg(void);
+void omap_hwmod_am43xx_reg(void);
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 598f813..d080bef 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -23,6 +23,7 @@
#include cm33xx.h
#include prm33xx.h
#include omap_hwmod_33xx_43xx_common_data.h
+#include prcm43xx.h
#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
#define RSTCTRL(oh, rstctrl) ((oh).prcm.omap4.rstctrl_offs = (rstctrl))
@@ -1380,3 +1381,76 @@ void omap_hwmod_am33xx_reg(void)
omap_hwmod_am33xx_clkctrl();
omap_hwmod_am33xx_rst();
}
+
+static void omap_hwmod_am43xx_clkctrl(void)
+{
+ CLKCTRL(am33xx_uart2_hwmod, AM43XX_CM_PER_UART1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart3_hwmod, AM43XX_CM_PER_UART2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart4_hwmod, AM43XX_CM_PER_UART3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart5_hwmod, AM43XX_CM_PER_UART4_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_uart6_hwmod, AM43XX_CM_PER_UART5_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan0_hwmod, AM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_dcan1_hwmod, AM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_elm_hwmod, AM43XX_CM_PER_ELM_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss0_hwmod, AM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss1_hwmod, AM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_epwmss2_hwmod, AM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio1_hwmod, AM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio2_hwmod, AM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_gpio3_hwmod, AM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c2_hwmod, AM43XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_i2c3_hwmod, AM43XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mailbox_hwmod, AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp0_hwmod, AM43XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mcasp1_hwmod, AM43XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc0_hwmod, AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_mmc1_hwmod, AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi0_hwmod, AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+ CLKCTRL(am33xx_spi1_hwmod, AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+
[PATCH v4 10/11] ARM: OMAP2+: AM43x: PRCM kbuild
Build AM43x power domain, clock domain and hwmod data. Many of AM43x IP's and interconnects are similar as that in AM335x, hence AM335x hwmod data is being reused with necessary changes. Earlier the plan was to reuse AM335x specific PRCM code, but as AM43x PRCM register layout is much similar to OMAP4/5, AM335x PRCM is divorced and instead married with OMAP4/5 PRCM for AM43x. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/Makefile | 7 ++- arch/arm/mach-omap2/cm33xx.h | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 0746494..cb7b527 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -112,13 +112,13 @@ obj-$(CONFIG_ARCH_OMAP2) += prm2xxx_3xxx.o prm2xxx.o cm2xxx.o obj-$(CONFIG_ARCH_OMAP3) += prm2xxx_3xxx.o prm3xxx.o cm3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o obj-$(CONFIG_SOC_AM33XX) += prm33xx.o cm33xx.o -obj-$(CONFIG_SOC_AM43XX) += prm33xx.o cm33xx.o omap-prcm-4-5-common = cminst44xx.o cm44xx.o prm44xx.o \ prcm_mpu44xx.o prminst44xx.o \ vc44xx_data.o vp44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common) +obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -146,6 +146,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= powerdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) obj-$(CONFIG_SOC_AM33XX) += powerdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(powerdomain-common) +obj-$(CONFIG_SOC_AM43XX) += powerdomains43xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= powerdomains54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += $(powerdomain-common) @@ -165,6 +166,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= clockdomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common) +obj-$(CONFIG_SOC_AM43XX) += clockdomains43xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += $(clockdomain-common) @@ -212,6 +214,9 @@ obj-$(CONFIG_ARCH_OMAP3)+= omap_hwmod_3xxx_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_43xx_interconnect_data.o obj-$(CONFIG_SOC_AM33XX) += omap_hwmod_33xx_43xx_ipblock_data.o +obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o +obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_interconnect_data.o +obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 757320b..cfb8891 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -383,7 +383,7 @@ void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs); void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs); void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs); -#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX) +#ifdef CONFIG_SOC_AM33XX extern int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs, u16 clkctrl_offs); extern void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs, -- 1.8.3.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 11/11] ARM: OMAP2+: AM43x PRCM init
From: Ambresh K ambr...@ti.com Initialise AM43x HWMOD, powerdomains and clockdomains. Signed-off-by: Ambresh K ambr...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/io.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index ff2113c..c90f647 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -594,7 +594,13 @@ void __init am43xx_init_early(void) NULL); omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE)); omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL); + omap_prm_base_init(); + omap_cm_base_init(); omap3xxx_check_revision(); + am43xx_powerdomains_init(); + am43xx_clockdomains_init(); + am43xx_hwmod_init(); + omap_hwmod_init_postsetup(); } #endif -- 1.8.3.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 0/9] ARM: dts: DT data for OMAP platforms for v3.13
Hi Joel, On 26/09/2013 00:01, Joel Fernandes wrote: Following series is a collection of dts patches for the below features: crypto: aes, sha on am335x aes, des on am437x aes, des on omap4 display: beaglebone black HDMI am335x-evm panel Series is based on Benoit Cousson's for_3.13/dts branch (commit sha 45646cd) Available at: g...@github.com:joelagnel/linux-kernel.git (branch for-benoit) Thanks for the update and rebase. I'll check the series ASAP. Thanks, Benoit Benoit Parrot (1): ARM: dts: AM33XX: Add LCDC info into am335x-evm Darren Etheridge (1): dts: boneblack: add pinmux and hdmi node to enable display Joel Fernandes (5): omap4: dts: Add node for AES omap4: dts: Add node for DES3DES module am33xx: dts: Fix AES interrupt number ARM: am437x: dts: Add AES node for am437x ARM: am437x: dts: Add DES node for am437x Mark A. Greer (2): ARM: dts: Add SHAM data and documentation for AM33XX ARM: dts: Add AES data and documentation for AM33XX .../devicetree/bindings/crypto/omap-aes.txt| 34 ++ .../devicetree/bindings/crypto/omap-sham.txt | 31 + arch/arm/boot/dts/am335x-bone.dts | 8 +++ arch/arm/boot/dts/am335x-boneblack.dts | 48 + arch/arm/boot/dts/am335x-evm.dts | 79 ++ arch/arm/boot/dts/am335x-evmsk.dts | 8 +++ arch/arm/boot/dts/am33xx.dtsi | 30 arch/arm/boot/dts/am4372.dtsi | 16 + arch/arm/boot/dts/omap4.dtsi | 20 ++ 9 files changed, 274 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt -- 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/9] omap4: dts: Add node for AES
On 26/09/2013 00:01, Joel Fernandes wrote:
OMAP4 has an AES module that uses the omap-aes crypto driver.
Add DT entries for the same.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 45708e1..4267a74 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -663,5 +663,15 @@
ram-bits = 12;
ti,has-mailbox;
};
+
+ aes: aes@4B501000 {
+ compatible = ti,omap4-aes;
+ ti,hwmods = aes;
+ reg = 0x4B501000 0xa0;
Nit: Please use lower case for hexa value.
+ interrupt-parent = gic;
You don't have to add the interrupt-parent, it is already set by default
at the root of the tree.
We did not add it for most nodes. Some are still there becasue I missed
them during the review :-)
+ interrupts = 0 85 0x4;
For interrupt, you should use the macros now for better readability.
+ interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
Regards,
Benoit
+ dmas = sdma 111, sdma 110;
+ dma-names = tx, rx;
+ };
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] usb: dwc3: msm: Add device tree binding information
On Mon, Sep 23, 2013 at 08:31:48PM +0100, Felipe Balbi wrote: Hi, On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com Any acks for the DT part ? This patch has been pending forever. Apologies for the delay. I have a couple of comments that would be nice to fix up now. --- .../devicetree/bindings/usb/msm-ssusb.txt | 104 1 file changed, 104 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt new file mode 100644 index 000..cacbd3b --- /dev/null +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt @@ -0,0 +1,104 @@ +MSM SuperSpeed DWC3 USB SoC controller + + +DWC3 Highspeed USB PHY +== +Required properities : +- compatible : sould be qcom,dwc3-hsphy; s/sould/should/ In general, compatible properties are should contain rather than should be, as we might have backwards compatible hardware in future. +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes Clocks are referred to be phandle + clock-specifier pairs rather than phandles, it would be nice to fix the terminology here +- clock-names : + xo : External reference clock 19 MHz + sleep_a : Sleep clock, used when USB3 core goes into low + power mode (U3). I think it would be nicer to say: - clocks : A list of phandle + clock-specifier pairs for the clocks listed in clock-names - clock-names: Should contain the following: xo - External reference clock (19MHz) sleep_a - Sleep clock used when USB3 core goes into low power mode (U3). I'm not sure we need to describe the frequency of the xo clock -- either it's a requriement of the IP and thus doesn't need to be a part of the binding, or it's configurable by the driver and thus doesn't need to be documented. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for HSPHY + v3p3 : 3.3v supply for HSPHY + vbus : vbus supply for host mode + vddcx : vdd supply for HS-PHY digital circuit operation Any reason for the HSPHY/HS-PHY difference? I'd list these separately with their full names: - v1p8-supply: phandle to the regulator for the 1.8v supply to HSPHY. - v3p3-supply: phandle to the regulator for the 3.3v supply to HSPHY. - vbus-supply: phandle to the regulator for the vbus supply for host mode. - vddcx-supply: phandle to the regulator for the vdd supply for HSPHY digital circuit operation. + +DWC3 Superspeed USB PHY +=== +Required properities : +- compatible : sould be qcom,dwc3-ssphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + ref : Reference clock - used in host mode. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for SS-PHY + vddcx : vdd supply for SS-PHY digital circuit operation The commments on compatible, clocks, clock-names and the regulators apply here. + +DWC3 controller wrapper +=== +Required properties : +- compatible : should be qcom,dwc3 +- reg : offset and length of the register set in the memory map + offset and length of the TCSR register for routing USB + signals to either picoPHY0 or picoPHY1. +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + core : Master/Core clock, have to be = 125 MHz for SS + operation and = 60MHz for HS operation + iface : System bus AXI clock + sleep : Sleep clock, used when USB3 core goes into low + power mode (U3). + utmi : Generated by HS-PHY. Used to clock the low power + parts of thr HS Link layer. +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. The commments on compatible, clocks, and clock-names apply here too. I see the regulator is defined individually :) I'm fine with the binding itself, I'd just like the documentation fixed up. Cheers, Mark. +Required child node: +A child node must exist to represent the core DWC3 IP block. The name of +the node is not important. The content of the node is defined in dwc3.txt. + +Example device nodes: + +
Re: [PATCH] OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
On Thu, Sep 26, 2013 at 11:36:26AM +0300, Tomi Valkeinen wrote: I wish we could select instead of depends on... We probably could. signature.asc Description: Digital signature
Re: [PATCH] OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
On 26/09/13 13:12, Mark Brown wrote: On Thu, Sep 26, 2013 at 11:36:26AM +0300, Tomi Valkeinen wrote: I wish we could select instead of depends on... We probably could. I'm not so sure. If we select BACKLIGHT_CLASS_DEVICE, we could end up compiling backlight.c without fbdev, and backlight.c uses fb's funcs. The funny thing is, there is FB_BACKLIGHT, which seems to be designed to be selectable (and is selected). That one depends on FB, but if I'm not mistaken, that dependency does not do anything if FB_BACKLIGHT is selected. FB_BACKLIGHT in turn selects both BACKLIGHT_LCD_SUPPORT and BACKLIGHT_CLASS_DEVICE, neither of which seem to be designed to be selectable. I think that's a bit broken. Anyway, I guess it's better to depend on here, to be on the safe side. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 00/11] ARM: OMAP2+: AM43x PRCM basic support
Hi, It seems, [PATCH v4 02/11] ARM: OMAP2+: hwmod: AM335x/AM43x: move common data is held on LAKML for moderator approval due to big size. I will wait for some time to see if moderator approves, if not, will ping him (believe it is David Woodhouse), but not sure how to get it into omap list though. Changes are also available @git://gitorious.org/x0148406-public/linux-kernel.git tags/am43x-prcm-v4 Regards Afzal On Thursday 26 September 2013 02:58 PM, Afzal Mohammed wrote: Hi Paul, Benoit, Tony, This series adds PRCM support (except clock tree) for AM43x SoC's. Current version is based on Rajendra's comments and discussions, please consider this for inclusion in the coming merge window. Major changes compared to v2 (v3 was only an rfc for current approach): 1. omap_hwmod_33xx_43xx_interconnect_data.c has the common interconnect ocp's structs shared between AM335x and AM43x 2. omap_hwmod_33xx_43xx_ipblock_data.c has the common hwmod structs shared between AM335x and AM43x 3. Instances where clock domain or clock topology has changed in the few cases, have separate structures for AM335x and AM43x 4. To handle scenarios where register offsets are different, they are dynamically init-ed in omap_hwmod_33xx_43xx_ipblock_data.c 5. Register offsets for hwmod's that are present either in AM335x or AM43x are updated statically in omap_hwmod_33xx_data.c or omap_hwmod_43xx_data.c as that was cleaner. Major changes compared to rfc v3: 1. All register offsets properly taken care for AM43x (with rfc v3, a couple of issues was detected while testing on pre-silicon) 2. There were two patches for common hwmod data movement (one for interconnect and other for ip block data), both were combined to have a cleaner series that is bisectable. 3. Cleaner seperation of common data This series has been boot tested on pre-silicon platform with the help of Tero's DT clock tree conversion series. This series has been tested on AM335x-EVM too. The change that re-introduces SW_SLEEP for OMAP4 has been left out from this series as it is the only potential change that affect other platforms. It will be taken care seperately. Additional details: AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. As AM43x PRCM register layout differs from AM335x and is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. Currently there is no public TRM available for AM43x. Changes based on: v3.12-rc2 Regards Afzal Afzal Mohammed (7): ARM: OMAP2+: hwmod: AM335x/AM43x: move common data ARM: OMAP2+: hwmod: AM335x: runtime register update ARM: OMAP2+: hwmod: AM335x: remove static register offs ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AM43x support ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 arch/arm/mach-omap2/Makefile |9 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c| 196 ++ arch/arm/mach-omap2/cm33xx.c | 16 +- arch/arm/mach-omap2/cm33xx.h | 12 +- arch/arm/mach-omap2/cminst44xx.c | 29 +- arch/arm/mach-omap2/cminst44xx.h | 26 +- arch/arm/mach-omap2/io.c |6 + arch/arm/mach-omap2/omap_hwmod.c |8 + arch/arm/mach-omap2/omap_hwmod.h |1 + .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 163 ++ .../omap_hwmod_33xx_43xx_interconnect_data.c | 643 +++ .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 1456 +++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1966 +--- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 622 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c| 142 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 18 files changed, 3438 insertions(+), 2003 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c create mode 100644 arch/arm/mach-omap2/omap_hwmod_43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 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
RE: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
From: Rob Herring [mailto:robherri...@gmail.com] From: Pekon Gupta [mailto:pe...@ti.com] diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index df338cb..958e5d5 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -21,11 +21,8 @@ Optional properties: is wired that way. If not specified, a bus width of 8 is assumed. - - ti,nand-ecc-opt:A string setting the ECC layout to use. One of: - - swSoftware method (default) - hwHardware method - hw-romcodegpmc hamming mode method romcode layout + - ti,nand-ecc-scheme: A string setting the ECC layout to use. One of: + ham1 1-bit Hamming ecc code As has been pointed out, this breaks compatibility which should be avoided unless you know the state of use of this binding. I fail to see the advantage of using scheme over opt. You could simply add ham1 here and maintain compatibility. Instead of removing sw, hw, etc. you can simply deprecate them or decide that the kernel doesn't support those options. Renaming 'ti,nand-ecc-opt' to 'ti,nand-ecc-scheme' was as per earlier comments from Olof. So either way is fine with me. Should I revert it back to 'ti,nand-ecc-opt' ? Also, sw, hw_romcode have been deprecated, they are no longer supported in driver. So shouldn't they be removed from the documentation ? However, since you are willing to break compatibility, then you should the generic NAND binding and use nand-ecc-mode adding the values you need. Documentation/devicetree/bindings/mtd/nand.txt: * MTD generic binding - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: none, soft, hw, hw_syndrome, hw_oob_first, soft_bch. Yes I can use generic 'nand-ecc-mode', But the binding values like soft, hw, soft_bch are too generic to describe the hardware. - BCH ECC scheme can itself be of multiple types, bch4/bch8/bch16 so soft_bch is ambiguous. - Similarly soft and hw do not determine the algorithm used like Hamming or BCH. (a) Should I update the generic binding values (if no one else is using) ? like sw - ham1_sw hw - ham1_hw soft_bch- soft_bch4, soft_bch8 OR (b) Should I add newer ones to it (like ham1, bch4, bch8, bch16) ? keeping the old ones intact. And how should I handle un-supported values, (Is pr_err during kernel probe enough ?). [...] - - elm_id: Specifies elm device node. This is required to support BCH - error correction using ELM module. + - ti,elm-id: Specifies pHandle of the ELM devicetree node. + ELM is an on-chip hardware engine on TI SoC which is used for + locating ECC errors for BCHx algorithms. SoC devices which have + ELM hardware engines should specify this device node in .dtsi + Using ELM for ECC error correction frees some CPU cycles. While yes, this is better name and documentation, I don't know that breaking compatibility is justified. As this is TI specific binding, so manufacturer's name should have been included. But as this was missed while adding this binding, so this should be fixed now. (Olof also recommended the same). AFAIK, For TI's NAND OMAP driver, currently there are not many end-users are using these bindings from mainline DT kernel. So this patch series mainly aims to cleanup NAND driver so that migrate to latest DT based kernel from board-file one is easy. So changes should be acceptable from end-user's point, its only matter of which path to take. Request you to please help me finalize this before I resend next patch series addressing other comments from Brian. + Mark Rutland mark.rutl...@arm.com + Pawel Moll pawel.m...@arm.com + Ian Campbell ijc+devicet...@hellion.org.uk + Stephen Warren swar...@wwwdotorg.org CC other DT maintainers, who were missed in this branch of mail-chain. with regards, pekon -- 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 39/51] DMA-API: others: use dma_set_coherent_mask()
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/ata/pata_ixp4xx_cf.c |5 -
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 1ec53f8..ddf470c 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct ixp4xx_pata_data *data = dev_get_platdata(pdev-dev);
+ int ret;
cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
return -ENOMEM;
/* acquire resources and fill host */
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
data-cs0 = devm_ioremap(pdev-dev, cs0-start, 0x1000);
data-cs1 = devm_ioremap(pdev-dev, cs1-start, 0x1000);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..81192d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ int ret;
+
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
return drm_platform_init(exynos_drm_driver, pdev);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..701c4c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
/* set dma mask for device */
- /* NOTE: this is a workaround for the hwmod not initializing properly */
- dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto fail;
Tested with omapdrm on omap4 panda es board.
Thanks,
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
*Changes v5 - v6* [PATCH 1/4]: - updated DT binding for gpmc-nand based on 'Olof Johansson's feedbacks http://lists.infradead.org/pipermail/linux-mtd/2013- August/048394.html - detection of ELM device via ti,elm-id DT node, moved to gpmc.c driver [PATCH 2/4] - removed: support for following obselete ECC schemes OMAP_ECC_HAMMING_CODE_DEFAULT (S/W based 1-bit Hamming ECC) OMAP_ECC_HAMMING_CODE_HW_ROMCODE (H/W based 1-bit Hamming ECC scheme) - updated: using omap_oobinfo as chip-ecc.layout for all ecc- schemes - clean: error messages [PATCH 3/4] cleaned to include changes for OMAP_ECC_BCH8_CODE_HW only [PATCH 4/4] updated to include DT property changes *Changes v4 - v5* - Rebased to linux-next IMPORTANT: Need to revert commit fb1585b, [PATCH 2/4] part of previous version http://lists.infradead.org/pipermail/linux-mtd/2013-July/047441.html - Swapped PATCH-1 PATCH-2 to maintain bisectibility compilation dependency http://lists.infradead.org/pipermail/linux-mtd/2013-July/047461.html - PATCH-2: re-ordered call to is_elm_present() for later updates ELM driver - dropped changes in include/linux/platform_data/elm.h (not needed) - PATCH-3: re-ordered call to is_elm_present() for later updates ELM driver - Re-formated patch description (replaced tabs with white-spaces) *Changes v3 - v4* (Resent with CC: devicetree-disc...@lists.ozlabs.org) - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 MTD_NAND_OMAP_BCH4 from nand/Kconfig ECC scheme selectable via nand DT (nand-ecc-opt). - [*] rebased for l2-mtd.git *Changes v2 - v3* (Resent with Author Name fixed) - PATCH-1: re-arranged code to remove redundancy, added NAND_BUSWIDTH_AUTO - PATCH-2: updated nand-ecc-opt DT mapping and Documentation - PATCH-3: code-cleaning + changes to match PATCH-1 - PATCH-4 DROPPED update DT attribute for ti,nand-ecc-opt - received feedback to keep DT mapping independent of linuxism - PATCH-4:NEW : ARM: dts: AM33xx: updated default ECC scheme in nand- ecc-opt - independent patch for AM335x-evm.dts update based on PATCH-2 *Changes v1 - v2* added [PATCH 3/4] and [PATCH 4/4] *Patches in this series* [PATCH 1/4]-[PATCH v5 2/4]: clean-up and optimization for supported ECC schemes. [PATCH 2/4]-[PATCH v5 1/4]: add separate DT options each supported ECC scheme. [PATCH 3/4]: update BCH4 ECC implementation (using ELM or using lib/bch.h) [PATCH 4/4]: ARM: dts: AM33xx: updated default ECC scheme in nand-ecc- opt After this patch series, omap2-nand driver will supports following ECC schemes: +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ - Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires, Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm. - Selection of OMAP_ECC_BCHx_CODE_HW requires, Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module. Pekon Gupta (4): ARM: OMAP2+: cleaned-up DT support of various ECC schemes mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe mtd:nand:omap2: updated support for BCH4 ECC scheme ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt .../devicetree/bindings/mtd/gpmc-nand.txt | 14 +- arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/mach-omap2/board-flash.c | 2 +- arch/arm/mach-omap2/gpmc.c | 47 +- drivers/mtd/nand/Kconfig | 30 +- drivers/mtd/nand/omap2.c | 526 ++--- include/linux/platform_data/mtd-nand-omap2.h | 18 +- 7 files changed, 309 insertions(+), 330 deletions(-) -- 1.8.1 + Rob Herring robherri...@gmail.com + Mark Rutland mark.rutl...@arm.com + Pawel Moll pawel.m...@arm.com + Ian Campbell ijc+devicet...@hellion.org.uk + Stephen Warren swar...@wwwdotorg.org CC other DT maintainers, who were missed earlier in mail-chain. with regards, pekon -- 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
RE: [PATCH v6 4/4] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Sep 12, 2013 at 05:20:19PM +0530, Pekon Gupta wrote:
DT property values for OMAP based gpmc-nand have been updated
to match changes in commit:
6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC
schemes
Whose commit ID is this? Your patch is not merged yet, so don't use a
commit ID.
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index e8ec875..e28a2ac 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -268,7 +268,7 @@
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-scheme = bch8;
gpmc,device-nand = true;
gpmc,device-width = 1;
gpmc,sync-clk-ps = 0;
This change should probably go in patch 1 anyway, when you break the
ABI.
As this patch series touches three different trees..
(1) arch/arm/boot/dts/.. maintained by Benoit Cousson
(benoit.cous...@linaro.org)
(2) arch/arm/mach-omap2/.. maintained by Tony Lindgren (t...@atomide.com)
(3) driver/mtd/nand/.. maintained by Brian Norris computersforpe...@gmail.com
It was observed that there were conflicts usually during final merge,
Hence I separated out the patches.
However, if all are in sync and the series gets committed in above trees
simultaneously, then this conflicts can be avoided.
So, if Tony Benoit are ok then I'll merge this [PATCH 4/4] in [PATCH 1/4].
with regards, pekon
--
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: DSS display-new custom enable/disable hooks
On 26/09/13 14:01, Dr. H. Nikolaus Schaller wrote: So this essentially means that the invert property and the bypass, acen properties should be defined for the VENC (if it also controls the DAC-Stage). I.e. I am not sure if invert is really a property (control) of the connector or an amplifier. Invert bit is programmed to VENC, so it is a property of VENC. At least in the end. The question is, does it need to be changed dynamically at runtime? I don't think so. OPA always wants its input inverted. Without OPA, the TV out signal is always un-inverted. So we can have it as a property of VENC, just like bypass and acen. True, it's currently set at the connector, but I think that's wrong. The OPA itself then should also participate in suspend/resume. Well, that would be something important for proper power management. Only then we can make sure the OPA is disabled correctly. There isn't really anything to suspend/resume on that level. If the display is enabled, it stays enabled, there's no automatic suspend. If there's a system suspend, omapfb (or similar component) will disable the displays. So it's only about enable/disable on this level. Ok. I think this is also sufficient since the OPA362 is in low power if it is disabled. I.e. suspend and disable are the same. I think that fits more or less all hardware. Well, sometimes there could be different power-states, and waking up from those takes different amounts of time. I think that's normally not needed for display, it doesn't matter if enabling a display encoder takes 15ms or 100ms. Although one could argue that one is just controlling the GPIO and the other one is controlling some regulator... Sorry, didn't understand that one... Well, this is perhaps a bit about semantics, but it is a driver for OPA362 hardware. Sure, we can make a more generic driver if we see that there are other external amps that have very similar controls. That was my assumption. Analog amplifiers just have an input and an output. And can be powered on or off. This would imho fit 99% of all such amplifiers. Well, one could think about switching different signal strenghts but this is AFAIK not defined by the composite video standards. Ok. But I would presume all of them have power and gpio inputs. Does the power need to be enabled before enabling the gpio, and if so, for how long does the power need to be enabled until the gpio can be set? Etc. I don't know if simple components like analog amp needs those, but very often display component datasheets list quite specifically the order and timing of all the powers and gpios. That said... Maybe a generic amp driver would work for the 99% of cases. It's always difficult to guess what kind of hardware there is out there =). But it's still an OPA362 driver, but it would also be OPA123, OPA321, etc. driver. Making it external-video-amplifier driver is probably taking it too far. We don't know what kind of amps there are. Maybe some are controlled via i2c. Dumping all the different functionality for different amps into one driver would just make one messy driver. Ok, I will start to write an amplifier-opa362.c based on the encoder-ftp410.c code. Yep, I don't have a strong opinion on whether to create opa362, or more generic driver. Try one =). That said, if the feature, invert in this case, never needs to be changed at runtime, there's no real reason to have that kind of method for OPA to change the inversion. So the board file could just pass the invert flag as a parameter to VENC. Yes, that is what I now also think. And the flag should/could be removed from the connector-analog-tv at all. I.e. I think the opa362 driver should have a call in-ops.atv-invert_vid_out_polarity(in, true); in the opa362_enable() code because it knows that it wants to see an inverted input. I think the whole function should be removed. Again, if there's no need to ever change it during runtime by OPA, the call is quite unnecessary. And the invert flag could just be passed to VENC in platform data. And note that with change it during runtime I don't mean VENC could not change it during runtime. If the bit needs to be cleared when the output is disabled, VENC can do that. But that is VENC's internal thing, no need for a invert_vid_out_polarity() API for it. Now how can we proceed? For the moment we could try to get the DEVCONF1 setup into the board_init until a DAC Stage driver and some platform independent API for DEVCONF1 modifications exists. Well, as I don't see the need for the DAC driver, I would just add the function pointers to change DEVCONF1 to struct omap_dss_board_info. Also, the flags to enable/disable invert, bypass and AC would be added to the same struct. An alternative could be that the opa362 driver can ask the VENC to set these values each time it is enabled. This would follow the backwards call chain you did describe and would be similar to
Re: DSS display-new custom enable/disable hooks
Am 26.09.2013 um 13:49 schrieb Tomi Valkeinen: On 26/09/13 14:01, Dr. H. Nikolaus Schaller wrote: So this essentially means that the invert property and the bypass, acen properties should be defined for the VENC (if it also controls the DAC-Stage). I.e. I am not sure if invert is really a property (control) of the connector or an amplifier. Invert bit is programmed to VENC, so it is a property of VENC. At least in the end. The question is, does it need to be changed dynamically at runtime? I don't think so. OPA always wants its input inverted. Without OPA, the TV out signal is always un-inverted. So we can have it as a property of VENC, just like bypass and acen. True, it's currently set at the connector, but I think that's wrong. Yes, this is how I would have argued as well. The OPA itself then should also participate in suspend/resume. Well, that would be something important for proper power management. Only then we can make sure the OPA is disabled correctly. There isn't really anything to suspend/resume on that level. If the display is enabled, it stays enabled, there's no automatic suspend. If there's a system suspend, omapfb (or similar component) will disable the displays. So it's only about enable/disable on this level. Ok. I think this is also sufficient since the OPA362 is in low power if it is disabled. I.e. suspend and disable are the same. I think that fits more or less all hardware. Well, sometimes there could be different power-states, and waking up from those takes different amounts of time. I think that's normally not needed for display, it doesn't matter if enabling a display encoder takes 15ms or 100ms. Although one could argue that one is just controlling the GPIO and the other one is controlling some regulator... Sorry, didn't understand that one... I meant that there could be a differece between enable/disable and power-on/off (e.g. retaining register values vs. loosing everything). But I can't imagine that for a simple video amplifier. Well, this is perhaps a bit about semantics, but it is a driver for OPA362 hardware. Sure, we can make a more generic driver if we see that there are other external amps that have very similar controls. That was my assumption. Analog amplifiers just have an input and an output. And can be powered on or off. This would imho fit 99% of all such amplifiers. Well, one could think about switching different signal strenghts but this is AFAIK not defined by the composite video standards. Ok. But I would presume all of them have power and gpio inputs. Does the power need to be enabled before enabling the gpio, and if so, for how long does the power need to be enabled until the gpio can be set? Etc. I don't know if simple components like analog amp needs those, but very often display component datasheets list quite specifically the order and timing of all the powers and gpios. That said... Maybe a generic amp driver would work for the 99% of cases. It's always difficult to guess what kind of hardware there is out there =). Yes, and therefore I think we should focus on the 362 first like the 410. But it's still an OPA362 driver, but it would also be OPA123, OPA321, etc. driver. Making it external-video-amplifier driver is probably taking it too far. We don't know what kind of amps there are. Maybe some are controlled via i2c. Dumping all the different functionality for different amps into one driver would just make one messy driver. Ok, I will start to write an amplifier-opa362.c based on the encoder-ftp410.c code. Yep, I don't have a strong opinion on whether to create opa362, or more generic driver. Try one =). Well, let's start with amplifier-opa362 and see if someone else ever needs a different one. And amplifier-generic would be a quite strange name... That said, if the feature, invert in this case, never needs to be changed at runtime, there's no real reason to have that kind of method for OPA to change the inversion. So the board file could just pass the invert flag as a parameter to VENC. Yes, that is what I now also think. And the flag should/could be removed from the connector-analog-tv at all. I.e. I think the opa362 driver should have a call in-ops.atv-invert_vid_out_polarity(in, true); in the opa362_enable() code because it knows that it wants to see an inverted input. I think the whole function should be removed. Again, if there's no need to ever change it during runtime by OPA, the call is quite unnecessary. And the invert flag could just be passed to VENC in platform data. Yes, that is how I also would prefer it. And note that with change it during runtime I don't mean VENC could not change it during runtime. If the bit needs to be cleared when the output is disabled, VENC can do that. But that is VENC's internal thing, no need for a invert_vid_out_polarity() API for it. Yes. Now how can we
Re: DSS display-new custom enable/disable hooks
On 26/09/13 15:37, Dr. H. Nikolaus Schaller wrote: Although one could argue that one is just controlling the GPIO and the other one is controlling some regulator... Sorry, didn't understand that one... I meant that there could be a differece between enable/disable and power-on/off (e.g. retaining register values vs. loosing everything). But I can't imagine that for a simple video amplifier. Ah, I see. I'd still say there's just enable/disable from outside point of view. It's the driver's job to make things work so that configuration values are retained. If the hardware component is turned off so that it loses register values, the driver should first store the configuration into memory. So internally there may be different power levels, maybe some kind of timers to switch the component totally off if it's been disabled for some time, or such. Externally, I don't think those need to be visible. Well, we can't boot w/o the board file yet for other reasons, i.e. a DT only approach isn't our target yet. Sure, I'm fine with board file only version. My point was just that the solution should not be such that it's impossible to support with DT. For example, callbacks to board files are not possible with DT, so a solution that relies on callbacks to board files will not be accepted. And similarly board init calls are not supported with DT, so not acceptable. I don't want to make this more confusing, but... I wonder about the connector_type field. It's only function is to pass the value to VENC, which will then work differently. And it's also something that cannot be changed at runtime. Perhaps that, too, should be moved to VENC's platform data. I was also thinking about this topic. Well, the connector type is correctly a property of the connector... But it logically controls some registers in the DAC Output stage. So I had thought that the opa362 driver will hand it over to the VENC and could check if it is really a composite video (since AFAIK the OPA can't be used in a S-Video sytem). But that again would be another chain of information flow from the connector to the VENC making their APIs dependent. Right. I'm a bit leaning towards having it in the VENC platform data, and removing it from the connector. Well, it's not directly related to the issue at hand. You may just pass the connector type through OPA, and we can look at changing the connector type later. But if you want to have a try with the connector type at the same time, please go ahead. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 1/4] usb: musb: move port reset to worker
musb_port_reset() sleeps, so we can't call it from atomic context. It
is, however, called from places inside musb_hub_control() while
musb-lock is held, which leads to a scheduling while atomic warning.
Fix this by moving the logic into a worker, and call it where the
function was previously called directly.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c| 7 +++
drivers/usb/musb/musb_core.h| 3 +++
drivers/usb/musb/musb_host.h| 2 ++
drivers/usb/musb/musb_virthub.c | 13 -
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 18e877f..2b9f4b4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1699,6 +1699,12 @@ static void musb_irq_work(struct work_struct *data)
}
}
+static void musb_port_reset_work(struct work_struct *data)
+{
+ struct musb *musb = container_of(data, struct musb, port_reset_work);
+ musb_port_reset(musb);
+}
+
/* --
* Init support
*/
@@ -1857,6 +1863,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
+ INIT_WORK(musb-port_reset_work, musb_port_reset_work);
/* attach to the IRQ */
if (request_irq(nIrq, musb-isr, 0, dev_name(dev), musb)) {
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 65f3917..9529512 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -294,6 +294,9 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
+ struct work_struct port_reset_work;
+ boolport_reset_state;
+
u16 hwvers;
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..843f48e 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
extern void musb_root_disconnect(struct musb *musb);
extern void musb_host_resume_root_hub(struct musb *musb);
extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_reset(struct musb *musb);
#else
static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
{
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)
{}
static inline void musb_host_resume_root_hub(struct musb *musb){}
static inline void musb_host_poll_rh_status(struct musb *musb) {}
static inline void musb_host_poke_root_hub(struct musb *musb) {}
+static inline void musb_port_reset(struct musb *musb) {}
#endif
struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index a523950..30b43a1 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -155,7 +155,7 @@ static void musb_port_suspend(struct musb *musb, bool
do_suspend)
}
}
-static void musb_port_reset(struct musb *musb, bool do_reset)
+void musb_port_reset(struct musb *musb)
{
u8 power;
void __iomem*mbase = musb-mregs;
@@ -173,7 +173,7 @@ static void musb_port_reset(struct musb *musb, bool
do_reset)
* the appropriate amount of time has passed
*/
power = musb_readb(mbase, MUSB_POWER);
- if (do_reset) {
+ if (musb-port_reset_state) {
/*
* If RESUME is set, we must make sure it stays minimum 20 ms.
@@ -356,8 +356,10 @@ int musb_hub_control(
/* finish RESET signaling? */
if ((musb-port1_status USB_PORT_STAT_RESET)
-time_after_eq(jiffies, musb-rh_timer))
- musb_port_reset(musb, false);
+time_after_eq(jiffies, musb-rh_timer)) {
+ musb-port_reset_state = false;
+ schedule_work(musb-port_reset_work);
+ }
/* finish RESUME signaling? */
if ((musb-port1_status MUSB_PORT_STAT_RESUME)
@@ -412,7 +414,8 @@ int musb_hub_control(
musb_start(musb);
break;
case USB_PORT_FEAT_RESET:
- musb_port_reset(musb, true);
+ musb-port_reset_state = true;
+ schedule_work(musb-port_reset_work);
break;
case USB_PORT_FEAT_SUSPEND:
musb_port_suspend(musb, true);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] usb: musb: call musb_port_suspend from musb_bus_suspend
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_host.c| 2 ++
drivers/usb/musb/musb_host.h| 2 ++
drivers/usb/musb/musb_virthub.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 9a2b8c8..2b60596 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8 devctl;
+ musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 843f48e..dcffea7 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
extern void musb_host_resume_root_hub(struct musb *musb);
extern void musb_host_poke_root_hub(struct musb *musb);
extern void musb_port_reset(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
#else
static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
{
@@ -123,6 +124,7 @@ static inline void musb_host_resume_root_hub(struct musb
*musb) {}
static inline void musb_host_poll_rh_status(struct musb *musb) {}
static inline void musb_host_poke_root_hub(struct musb *musb) {}
static inline void musb_port_reset(struct musb *musb) {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
#endif
struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 30b43a1..9f3a0f3 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -90,7 +90,7 @@ static void musb_start(struct musb *musb)
musb_writeb(regs, MUSB_DEVCTL, devctl);
}
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
{
struct usb_otg *otg = musb-xceiv-otg;
u8 power;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] usb: musb: conditionally restore and resume the context on resume
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.
The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c | 17 -
include/linux/usb/musb.h | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2b9f4b4..f17604e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2152,6 +2152,7 @@ static int musb_suspend(struct device *dev)
{
struct musb *musb = dev_to_musb(dev);
unsigned long flags;
+ struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
spin_lock_irqsave(musb-lock, flags);
@@ -2165,16 +2166,30 @@ static int musb_suspend(struct device *dev)
*/
}
+ if (plat-restore_after_suspend)
+ musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
}
static int musb_resume_noirq(struct device *dev)
{
- /* for static cmos like DaVinci, register values were preserved
+ struct musb *musb = dev_to_musb(dev);
+ struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
+
+ /*
+* For static cmos like DaVinci, register values were preserved
* unless for some reason the whole soc powered down or the USB
* module got reset through the PSC (vs just being disabled).
+*
+* The plaform data tells us about the necessity of saving and
+* restoring the context across a suspend cycle.
*/
+
+ if (plat-restore_after_suspend)
+ musb_restore_context(musb);
+
return 0;
}
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..296be6c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -100,6 +100,7 @@ struct musb_hdrc_platform_data {
u8 mode;
u8 has_mailbox:1;
+ u8 restore_after_suspend:1;
/* for clk_get() */
const char *clock;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] usb: musb: support for suspend and resume
I've been working on some patches that allow suspending and resuming the musb-dsps platform. This was tested for host mode only. With these patches applied, I can successfully bring an AM335x board to suspend with a USB media connected, and access it again after resume. Note that this currently only works with CONFIG_MUSB_PIO_ONLY set. The cppi41 driver needs some more love to make this work. I'll work on that next. Thanks, Daniel Daniel Mack (4): usb: musb: move port reset to worker usb: musb: call musb_port_suspend from musb_bus_suspend usb: musb: conditionally restore and resume the context on resume usb: musb: dsps: add support for suspend and resume drivers/usb/musb/musb_core.c| 24 +- drivers/usb/musb/musb_core.h| 3 +++ drivers/usb/musb/musb_dsps.c| 54 + drivers/usb/musb/musb_host.c| 2 ++ drivers/usb/musb/musb_host.h| 4 +++ drivers/usb/musb/musb_virthub.c | 15 +++- include/linux/usb/musb.h| 1 + 7 files changed, 96 insertions(+), 7 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] usb: musb: dsps: add support for suspend and resume
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 4047cbb..c93c365 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -110,6 +110,17 @@ struct dsps_musb_wrapper {
u8 poll_seconds;
};
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+ u32 control;
+ u32 epintr;
+ u32 coreintr;
+ u32 phy_utmi;
+ u32 mode;
+};
+
/**
* DSPS glue structure.
*/
@@ -119,6 +130,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+ struct dsps_context context;
};
/**
@@ -502,6 +515,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+ pdata.restore_after_suspend = 1;
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -623,11 +637,51 @@ static const struct of_device_id musb_dsps_of_match[] = {
};
MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ glue-context.control = dsps_readl(mbase, wrp-control);
+ glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+ glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+ glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+ glue-context.mode = dsps_readl(mbase, wrp-mode);
+
+ return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+ struct dsps_glue *glue = dev_get_drvdata(dev);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb = platform_get_drvdata(glue-musb);
+ void __iomem *mbase = musb-ctrl_base;
+
+ dsps_writel(mbase, wrp-control, glue-context.control);
+ dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+ dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+ dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+ dsps_writel(mbase, wrp-mode, glue-context.mode);
+
+ musb-port_reset_state = false;
+ schedule_work(musb-port_reset_work);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
static struct platform_driver dsps_usbss_driver = {
.probe = dsps_probe,
.remove = dsps_remove,
.driver = {
.name = musb-dsps,
+ .pm = dsps_pm_ops,
.of_match_table = of_match_ptr(musb_dsps_of_match),
},
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 4/4] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
On Thu, Sep 26, 2013 at 1:28 PM, Gupta, Pekon pe...@ti.com wrote:
From: Brian Norris [mailto:computersforpe...@gmail.com]
On Thu, Sep 12, 2013 at 05:20:19PM +0530, Pekon Gupta wrote:
DT property values for OMAP based gpmc-nand have been updated
to match changes in commit:
6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC
schemes
Whose commit ID is this? Your patch is not merged yet, so don't use a
commit ID.
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index e8ec875..e28a2ac 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -268,7 +268,7 @@
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-scheme = bch8;
gpmc,device-nand = true;
gpmc,device-width = 1;
gpmc,sync-clk-ps = 0;
This change should probably go in patch 1 anyway, when you break the
ABI.
As this patch series touches three different trees..
(1) arch/arm/boot/dts/.. maintained by Benoit Cousson
(benoit.cous...@linaro.org)
Hi Pekon,
Please note that Benoit's current email address is bcous...@baylibre.com.
I had cc'ed him now with the correct address.
(2) arch/arm/mach-omap2/.. maintained by Tony Lindgren (t...@atomide.com)
(3) driver/mtd/nand/.. maintained by Brian Norris
computersforpe...@gmail.com
It was observed that there were conflicts usually during final merge,
Hence I separated out the patches.
However, if all are in sync and the series gets committed in above trees
simultaneously, then this conflicts can be avoided.
So, if Tony Benoit are ok then I'll merge this [PATCH 4/4] in [PATCH 1/4].
with regards, pekon
--
Best regards,
Javier
--
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/2] mmc: omap_hsmmc: Enable SDIO interrupt
Hi,
* Andreas Fenkart afenk...@gmail.com [130926 01:34]:
2013/9/26 Tony Lindgren t...@atomide.com:
@@ -463,27 +469,34 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, ISE, 0);
OMAP_HSMMC_WRITE(host-base, IE, 0);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
This is wrong. SDIO IRQ must not be disabled upon host initiated transfer.
see omap_hsmmc_request_done
Hmm I don't quite follow you here, are you saying that
omap_hsmmc_request_done() should call this conditionally?
Or maybe even do a patch on top of this based on what you discovered
with your earlier patches?
I know we don't have the remuxing support yet, but that has
dependencies to the pending pinctrl wake-up handling in general,
and pinctrl state grouping. So let's remove those dependencies
for now and get the basics going first before moving on to
the remuxing part :)
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1040,8 +1053,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
+ if (host-req_in_progress)
+ omap_hsmmc_do_irq(host, status);
+
+ if (status CIRQ_EN)
+ mmc_signal_sdio_irq(host-mmc);
/* Flush posted write */
status = OMAP_HSMMC_READ(host-base, STAT);
@@ -1556,6 +1573,43 @@ static void omap_hsmmc_init_card(struct mmc_host
*mmc, struct mmc_card *card)
mmc_slot(host).init_card(card);
}
+static void omap_hsmmc_enable_sdio_irq_nolock(struct omap_hsmmc_host *host,
+int enable)
+{
+ u32 irq_mask;
+
+ if (enable)
+ host-flags |= HSMMC_SDIO_IRQ_ENABLED;
+ else
+ host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
+
+ /* SDIO IRQ will be enabled as appropriate in runtime resume */
+ if (host-flags HSMMC_RUNTIME_SUSPENDED)
+ goto out;
Not sure here, will the module still come out of suspend even with
SDIO IRQ disabled?
Otherwise nak, sdio irq must enabled independent of pm runtime state. In the
worst case need pm_runtime_get().
Well this handling is similar to what's done in sdhci.c and
seems to work for me for off-idle on 3730. In that case the
whole MMC block is powered off and the wake up follows the
dedicated io chain path. For the am33xx off-idle case, the
wake-up path would be remuxed to the GPIO in the first GPIO
bank that's always on, so again the whole MMC block is off.
Maybe try to test this with your case with some additional
patches?
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1608,7 +1662,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
.init_card = omap_hsmmc_init_card,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
What about am335x, if this patch goes in, it will break that platform.
quirk flag via device tree?
I think it should still work, except the wake-up won't work for
the off-idle case unless the SDIO interrupt is remux to the
GPIO input?
If there are other issues then yes, we can use the compatible
flags.
Thanks for the review and comments,
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 2/2] mmc: omap_hsmmc: Enable SDIO interrupt
On Thursday 26 September 2013 07:49 PM, Tony Lindgren wrote:
Hi,
* Andreas Fenkart afenk...@gmail.com [130926 01:34]:
2013/9/26 Tony Lindgren t...@atomide.com:
@@ -463,27 +469,34 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, ISE, 0);
OMAP_HSMMC_WRITE(host-base, IE, 0);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
This is wrong. SDIO IRQ must not be disabled upon host initiated transfer.
see omap_hsmmc_request_done
Hmm I don't quite follow you here, are you saying that
omap_hsmmc_request_done() should call this conditionally?
Or maybe even do a patch on top of this based on what you discovered
with your earlier patches?
Hi Tony,
Resetting CIRQ_ENABLE in ISE and IE, clears the (latched) pending CIRQ_EN
if set in STAT register and also disables SDIO interrupt during interrupt
period (outside of command/data transaction).
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+
+ /* no transfer running, need to signal cirq if */
+ if (host-sdio_irq_en)
+ irq_mask |= CIRQ_EN;
+
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
I will try testing these patches with above code change and let you know
--
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 14/27] mmc: omap_hsmmc: Move away from using deprecated APIs
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs. Additional cleanup done for keeping track
suspended state.
Cc: Balaji T K balaj...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/omap_hsmmc.c | 37 +++--
1 file changed, 3 insertions(+), 34 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6ac63df..eb6fb28 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -170,7 +170,6 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char bus_mode;
unsigned char power_mode;
- int suspended;
int irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
@@ -1178,9 +1177,6 @@ static irqreturn_t omap_hsmmc_detect(int irq, void
*dev_id)
struct omap_mmc_slot_data *slot = mmc_slot(host);
int carddetect;
- if (host-suspended)
- return IRQ_HANDLED;
-
sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);
if (slot-card_detect)
@@ -1643,11 +1639,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
seq_printf(s, mmc%d:\n ctx_loss:\t%d:%d\n\nregs:\n,
mmc-index, host-context_loss, context_loss);
- if (host-suspended) {
- seq_printf(s, host suspended, can't read registers\n);
- return 0;
- }
-
pm_runtime_get_sync(host-dev);
seq_printf(s, CON:\t\t0x%08x\n,
@@ -2119,23 +2110,12 @@ static void omap_hsmmc_complete(struct device *dev)
static int omap_hsmmc_suspend(struct device *dev)
{
- int ret = 0;
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
if (!host)
return 0;
- if (host host-suspended)
- return 0;
-
pm_runtime_get_sync(host-dev);
- host-suspended = 1;
- ret = mmc_suspend_host(host-mmc);
-
- if (ret) {
- host-suspended = 0;
- goto err;
- }
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER)) {
omap_hsmmc_disable_irq(host);
@@ -2145,23 +2125,19 @@ static int omap_hsmmc_suspend(struct device *dev)
if (host-dbclk)
clk_disable_unprepare(host-dbclk);
-err:
+
pm_runtime_put_sync(host-dev);
- return ret;
+ return 0;
}
/* Routine to resume the MMC device */
static int omap_hsmmc_resume(struct device *dev)
{
- int ret = 0;
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
if (!host)
return 0;
- if (host !host-suspended)
- return 0;
-
pm_runtime_get_sync(host-dev);
if (host-dbclk)
@@ -2172,16 +2148,9 @@ static int omap_hsmmc_resume(struct device *dev)
omap_hsmmc_protect_card(host);
- /* Notify the core to resume the host */
- ret = mmc_resume_host(host-mmc);
- if (ret == 0)
- host-suspended = 0;
-
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
-
- return ret;
-
+ return 0;
}
#else
--
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 13/27] mmc: omap: Remove redundant suspend and resume callbacks
Suspend and resume of cards are handled by the protocol layer and
consequently the mmc_suspend|resume_host APIs are marked as deprecated.
While moving away from using the deprecated APIs, there are nothing
left to be done for the suspend and resume callbacks, so remove them.
Cc: Jarkko Lavinen jarkko.lavi...@nokia.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/omap.c | 53 ---
1 file changed, 53 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index b94f38e..0b10a90 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -128,7 +128,6 @@ struct mmc_omap_slot {
struct mmc_omap_host {
int initialized;
- int suspended;
struct mmc_request *mrq;
struct mmc_command *cmd;
struct mmc_data * data;
@@ -1513,61 +1512,9 @@ static int mmc_omap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-static int mmc_omap_suspend(struct platform_device *pdev, pm_message_t mesg)
-{
- int i, ret = 0;
- struct mmc_omap_host *host = platform_get_drvdata(pdev);
-
- if (host == NULL || host-suspended)
- return 0;
-
- for (i = 0; i host-nr_slots; i++) {
- struct mmc_omap_slot *slot;
-
- slot = host-slots[i];
- ret = mmc_suspend_host(slot-mmc);
- if (ret 0) {
- while (--i = 0) {
- slot = host-slots[i];
- mmc_resume_host(slot-mmc);
- }
- return ret;
- }
- }
- host-suspended = 1;
- return 0;
-}
-
-static int mmc_omap_resume(struct platform_device *pdev)
-{
- int i, ret = 0;
- struct mmc_omap_host *host = platform_get_drvdata(pdev);
-
- if (host == NULL || !host-suspended)
- return 0;
-
- for (i = 0; i host-nr_slots; i++) {
- struct mmc_omap_slot *slot;
- slot = host-slots[i];
- ret = mmc_resume_host(slot-mmc);
- if (ret 0)
- return ret;
-
- host-suspended = 0;
- }
- return 0;
-}
-#else
-#define mmc_omap_suspend NULL
-#define mmc_omap_resumeNULL
-#endif
-
static struct platform_driver mmc_omap_driver = {
.probe = mmc_omap_probe,
.remove = mmc_omap_remove,
- .suspend= mmc_omap_suspend,
- .resume = mmc_omap_resume,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
--
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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On 09/25/2013 03:48 AM, Tero Kristo wrote: [...] Test branch available here: https://github.com/t-kristo/linux-pm.git branch: mainline-3.12-rc2-ti-dt-clks-v7 Testing done: - am335x-bone : boot only - omap5-sevm : boot only - dra7-evm : boot only - omap3-beagle : boot + suspend/resume (ret + off) - omap4-panda-es : boot + suspend/resume Nishanth has also been doing some tests with omap3-beagle-xm with some WIP versions of this branch, but not with this latest one. Nishanth, maybe you can provide test results to this one also? I rebased the branch on top of benoit's for_3.13/dts merged with v3.12-rc2 tag 45646cd ARM: dts: AM33XX: don't redefine OCP bus and device nodes All platforms were to MMC filesystem boot (SD card). u-boot used v2013.10-rc3 on all platforms (mainline u-boot). OMAP3630: Beagle-XM: http://pastebin.pandaboard.org/index.php/view/96577127 (needs additional patch - https://patchwork.kernel.org/patch/2919661/ ) OMAP4460: Panda-ES: http://pastebin.pandaboard.org/index.php/view/85143661 OMAP5432: OMAP5-UEVM: http://pastebin.pandaboard.org/index.php/view/91361843 (nice to have patch - https://patchwork.kernel.org/patch/2907761/ ) AM335x: BeagleBone Black: http://pastebin.pandaboard.org/index.php/view/42000597 (needs additional patches: https://patchwork.kernel.org/patch/2902711/ https://patchwork.kernel.org/patch/2902711/ ) DRA7: DRA7-EVM: http://pastebin.pandaboard.org/index.php/view/38362805 (needs additional patches: - https://patchwork.kernel.org/patch/2849391/ - https://patchwork.kernel.org/patch/2849601/ - https://patchwork.kernel.org/patch/2849602/ - https://patchwork.kernel.org/patch/2907761/ ) So, for the entire series: Tested-by: Nishanth Menon n...@ti.com -- 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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On 09/26/2013 10:21 AM, Nishanth Menon wrote: On 09/25/2013 03:48 AM, Tero Kristo wrote: [...] Test branch available here: https://github.com/t-kristo/linux-pm.git branch: mainline-3.12-rc2-ti-dt-clks-v7 Testing done: - am335x-bone : boot only - omap5-sevm : boot only - dra7-evm : boot only - omap3-beagle : boot + suspend/resume (ret + off) - omap4-panda-es : boot + suspend/resume Nishanth has also been doing some tests with omap3-beagle-xm with some WIP versions of this branch, but not with this latest one. Nishanth, maybe you can provide test results to this one also? I rebased the branch on top of benoit's for_3.13/dts merged with v3.12-rc2 tag 45646cd ARM: dts: AM33XX: don't redefine OCP bus and device nodes All platforms were to MMC filesystem boot (SD card). u-boot used v2013.10-rc3 on all platforms (mainline u-boot). OMAP3630: Beagle-XM: http://pastebin.pandaboard.org/index.php/view/96577127 (needs additional patch - https://patchwork.kernel.org/patch/2919661/ ) dependency patch needs rework OMAP4460: Panda-ES: http://pastebin.pandaboard.org/index.php/view/85143661 OMAP5432: OMAP5-UEVM: http://pastebin.pandaboard.org/index.php/view/91361843 (nice to have patch - https://patchwork.kernel.org/patch/2907761/ ) Acked,tested, pending merge from maintainers AM335x: BeagleBone Black: http://pastebin.pandaboard.org/index.php/view/42000597 (needs additional patches: https://patchwork.kernel.org/patch/2902711/ - merged to Shekar's davinci branch - pending upstream. https://patchwork.kernel.org/patch/2902711/ Correction on ^^: should have been: https://patchwork.kernel.org/patch/2919661/ tested, pending ack, merge. ) DRA7: DRA7-EVM: http://pastebin.pandaboard.org/index.php/view/38362805 (needs additional patches: - https://patchwork.kernel.org/patch/2849391/ - https://patchwork.kernel.org/patch/2849601/ - https://patchwork.kernel.org/patch/2849602/ - https://patchwork.kernel.org/patch/2907761/ All of the above: Acked,tested, pending merge from maintainers ) So, for the entire series: Tested-by: Nishanth Menon n...@ti.com Maybe Benoit and Tony could help reduce few of these acked patches pending merge from having to be cherry-picked by folks. -- 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: [PATCHv7 30/36] ARM: dts: omap3 clock data
On 11:48-20130925, Tero Kristo wrote:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 16420ae..bc11b83 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -533,4 +533,11 @@
ram-bits = 12;
};
};
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ /include/ omap3xxx-clocks.dtsi
+ };
};
Clocks are introduced towards the tail of the dts - this has a problem
associated with it - device nodes should be able to reference phandle
like:
devicex {
clocks = sys_ck;
}
Since all the devices on ocp and cpu0 node appears above the definition
they fail to catch the phandle. instead, moving the clocks node as high
in the tree as possible resolves this: something like:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index bc11b83..0b2161d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -24,6 +24,13 @@
serial2 = uart3;
};
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ /include/ omap3xxx-clocks.dtsi
+ };
+
cpus {
#address-cells = 1;
#size-cells = 0;
@@ -534,10 +541,4 @@
};
};
- clocks {
- #address-cells = 1;
- #size-cells = 1;
- ranges;
- /include/ omap3xxx-clocks.dtsi
- };
};
What do you think of the change? applies for all clock nodes in other
dtsi as well - I will mark them as I find them.
Further,
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 5355d61..2ed7c69 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -25,4 +25,123 @@
clock-latency = 30; /* From legacy driver */
};
};
-};
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
dont need to state the above two - already done in omap3.dtsi.
+ /include/ omap34xx-omap36xx-clocks.dtsi
+ /include/ omap36xx-omap3430es2plus-clocks.dtsi
+ /include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
+ };
+};
[...]
\ No newline at end of file
^^
[...]
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index f8b3765..71fb6fb 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -35,4 +35,124 @@
clock-frequency = 4800;
};
};
-};
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
^^ here as well.
+ /include/ omap36xx-clocks.dtsi
+ /include/ omap34xx-omap36xx-clocks.dtsi
+ /include/ omap36xx-omap3430es2plus-clocks.dtsi
+ /include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
+ };
[...]
+};
\ No newline at end of file
^^ this need fix as well.
--
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: [PATCHv7 30/36] ARM: dts: omap3 clock data
On 09/26/2013 11:06 AM, Nishanth Menon wrote:
On 11:48-20130925, Tero Kristo wrote:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 16420ae..bc11b83 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -533,4 +533,11 @@
ram-bits = 12;
};
};
+
+clocks {
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+/include/ omap3xxx-clocks.dtsi
+};
};
Clocks are introduced towards the tail of the dts - this has a problem
associated with it - device nodes should be able to reference phandle
like:
devicex {
clocks = sys_ck;
}
Since all the devices on ocp and cpu0 node appears above the definition
they fail to catch the phandle. instead, moving the clocks node as high
in the tree as possible resolves this: something like:
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index bc11b83..0b2161d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -24,6 +24,13 @@
serial2 = uart3;
};
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ /include/ omap3xxx-clocks.dtsi
+ };
+
cpus {
#address-cells = 1;
#size-cells = 0;
@@ -534,10 +541,4 @@
};
};
- clocks {
- #address-cells = 1;
- #size-cells = 1;
- ranges;
- /include/ omap3xxx-clocks.dtsi
- };
};
What do you think of the change? applies for all clock nodes in other
dtsi as well - I will mark them as I find them.
Digging further, the above is not needed. Apologies on the noise.
below changes will be nice though..
Further,
diff --git a/arch/arm/boot/dts/omap34xx.dtsi
b/arch/arm/boot/dts/omap34xx.dtsi
index 5355d61..2ed7c69 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -25,4 +25,123 @@
clock-latency = 30; /* From legacy driver */
};
};
-};
+
+clocks {
+#address-cells = 1;
+#size-cells = 1;
+ranges;
dont need to state the above two - already done in omap3.dtsi.
+/include/ omap34xx-omap36xx-clocks.dtsi
+/include/ omap36xx-omap3430es2plus-clocks.dtsi
+/include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
+};
+};
[...]
\ No newline at end of file
^^
[...]
diff --git a/arch/arm/boot/dts/omap36xx.dtsi
b/arch/arm/boot/dts/omap36xx.dtsi
index f8b3765..71fb6fb 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -35,4 +35,124 @@
clock-frequency = 4800;
};
};
-};
+
+clocks {
+#address-cells = 1;
+#size-cells = 1;
+ranges;
^^ here as well.
+/include/ omap36xx-clocks.dtsi
+/include/ omap34xx-omap36xx-clocks.dtsi
+/include/ omap36xx-omap3430es2plus-clocks.dtsi
+/include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
+};
[...]
+};
\ No newline at end of file
^^ this need fix as well.
--
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 v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
On Thu, Sep 26, 2013 at 11:54:39AM +0100, Gupta, Pekon wrote: From: Rob Herring [mailto:robherri...@gmail.com] From: Pekon Gupta [mailto:pe...@ti.com] diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index df338cb..958e5d5 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -21,11 +21,8 @@ Optional properties: is wired that way. If not specified, a bus width of 8 is assumed. - - ti,nand-ecc-opt:A string setting the ECC layout to use. One of: - - swSoftware method (default) - hwHardware method - hw-romcodegpmc hamming mode method romcode layout + - ti,nand-ecc-scheme: A string setting the ECC layout to use. One of: + ham1 1-bit Hamming ecc code As has been pointed out, this breaks compatibility which should be avoided unless you know the state of use of this binding. I fail to see the advantage of using scheme over opt. You could simply add ham1 here and maintain compatibility. Instead of removing sw, hw, etc. you can simply deprecate them or decide that the kernel doesn't support those options. Renaming 'ti,nand-ecc-opt' to 'ti,nand-ecc-scheme' was as per earlier comments from Olof. So either way is fine with me. Should I revert it back to 'ti,nand-ecc-opt' ? I think that if the binding is already in use then we shouldn't break it, unless you're _definitely_ the only user. Also, sw, hw_romcode have been deprecated, they are no longer supported in driver. So shouldn't they be removed from the documentation ? Deprecated properties should be marked as deprecated, but continue to be documented. That at least prevents the names being repurposed in an incompatible way, and explains to anyone who looks at the document that the proeprty is deprecated rather than simply undocumented. However, since you are willing to break compatibility, then you should the generic NAND binding and use nand-ecc-mode adding the values you need. Documentation/devicetree/bindings/mtd/nand.txt: * MTD generic binding - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: none, soft, hw, hw_syndrome, hw_oob_first, soft_bch. Yes I can use generic 'nand-ecc-mode', But the binding values like soft, hw, soft_bch are too generic to describe the hardware. - BCH ECC scheme can itself be of multiple types, bch4/bch8/bch16 so soft_bch is ambiguous. It does indeed seem like the generic properties are not generic enough, at least from my quick look other them. However, I am not familiar with NAND, so I may have misunderstood. - Similarly soft and hw do not determine the algorithm used like Hamming or BCH. (a) Should I update the generic binding values (if no one else is using) ? like sw - ham1_sw hw - ham1_hw soft_bch- soft_bch4, soft_bch8 What do the current property names actually correspond to logically? If we did this and there are existing users, the old DTs need to continue functioning. OR (b) Should I add newer ones to it (like ham1, bch4, bch8, bch16) ? keeping the old ones intact. And how should I handle un-supported values, (Is pr_err during kernel probe enough ?). I think something like this, but with the names from (a) would be preferrable. [...] - - elm_id: Specifies elm device node. This is required to support BCH - error correction using ELM module. + - ti,elm-id: Specifies pHandle of the ELM devicetree node. + ELM is an on-chip hardware engine on TI SoC which is used for + locating ECC errors for BCHx algorithms. SoC devices which have + ELM hardware engines should specify this device node in .dtsi + Using ELM for ECC error correction frees some CPU cycles. While yes, this is better name and documentation, I don't know that breaking compatibility is justified. As this is TI specific binding, so manufacturer's name should have been included. But as this was missed while adding this binding, so this should be fixed now. (Olof also recommended the same). We could update the binding to prefer ti,elm-id, and deprecate elm_id while maintaining support in the kernel. Thanks, Mark. AFAIK, For TI's NAND OMAP driver, currently there are not many end-users are using these bindings from mainline DT kernel. So this patch series mainly aims to cleanup NAND driver so that migrate to latest DT based kernel from board-file one is easy. So changes should be acceptable from end-user's point, its
Re: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
[I see Mark made some of the same comments while I was typing this email] On Thu, Sep 26, 2013 at 06:08:42AM +, Gupta, Pekon wrote: From: Rob Herring [mailto:robherri...@gmail.com] From: Pekon Gupta [mailto:pe...@ti.com] diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index df338cb..958e5d5 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -21,11 +21,8 @@ Optional properties: is wired that way. If not specified, a bus width of 8 is assumed. - - ti,nand-ecc-opt:A string setting the ECC layout to use. One of: - - swSoftware method (default) - hwHardware method - hw-romcodegpmc hamming mode method romcode layout + - ti,nand-ecc-scheme: A string setting the ECC layout to use. One of: + ham1 1-bit Hamming ecc code As has been pointed out, this breaks compatibility which should be avoided unless you know the state of use of this binding. I fail to see the advantage of using scheme over opt. You could simply add ham1 here and maintain compatibility. Instead of removing sw, hw, etc. you can simply deprecate them or decide that the kernel doesn't support those options. Renaming 'ti,nand-ecc-opt' to 'ti,nand-ecc-scheme' was as per earlier comments from Olof. So either way is fine with me. Should I revert it back to 'ti,nand-ecc-opt' ? Also, sw, hw_romcode have been deprecated, they are no longer supported in driver. So shouldn't they be removed from the documentation ? I think leaving them in the documentation but marking them as deprecated makes sense. However, since you are willing to break compatibility, then you should the generic NAND binding and use nand-ecc-mode adding the values you need. Documentation/devicetree/bindings/mtd/nand.txt: * MTD generic binding - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: none, soft, hw, hw_syndrome, hw_oob_first, soft_bch. Yes I can use generic 'nand-ecc-mode', But the binding values like soft, hw, soft_bch are too generic to describe the hardware. - BCH ECC scheme can itself be of multiple types, bch4/bch8/bch16 so soft_bch is ambiguous. - Similarly soft and hw do not determine the algorithm used like Hamming or BCH. (a) Should I update the generic binding values (if no one else is using) ? like sw - ham1_sw hw - ham1_hw soft_bch- soft_bch4, soft_bch8 OR (b) Should I add newer ones to it (like ham1, bch4, bch8, bch16) ? keeping the old ones intact. And how should I handle un-supported values, (Is pr_err during kernel probe enough ?). The existing nand-ecc-mode binding is a bit peculiar and hard to maintain generically for all NAND, IMO. ECC is often very specific to each driver/controller. What's to say that a given software BCH4 library (such as the one found in Linux) will match a given controller's HW BCH4 layout and encoding format? Perhaps Pekon's OMAP NAND driver can straighten things out such that HW and SW ECC are interchangeable for a given BCH mode, but we can't guarantee all drivers/controllers make this possible. So, what's the advantage of using this generic binding (nand-ecc-mode) for all NAND hardware instead of defining distinct hardware-specific bindings for different sets of hardware? The former seems like we will clutter up the nand-ecc-mode namespace such that any one set of hardware/software will only support a small subset of the potential options. And it doesn't seem to win us a lot. What's more, this single binding doesn't seem flexible enough for the hardware I deal with. I have a NAND controller whose ECC HW can be programmed to one of dozens of different ECC modes, parameterized by strength (i.e., BCH-x, where x varies) and ECC step/sector size (i.e., each ECC block covers 512B or 1024B of data). So I'm not convinced that extending this nand-ecc-mode property is correct at all. But if we do want to, perhaps we'd need to introduce additional orthogonal properties to specify strength and step size, rather than listing all combinations as separate values for nand-ecc-mode. Brian -- 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 v11 2/8] usb: phy: omap-usb2: use the new generic PHY framework
On Wed, Aug 21, 2013 at 11:16:07AM +0530, Kishon Vijay Abraham I wrote:
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile |1 +
drivers/{usb = }/phy/phy-omap-usb2.c | 45
++---
drivers/usb/phy/Kconfig | 10
drivers/usb/phy/Makefile |1 -
5 files changed, 54 insertions(+), 15 deletions(-)
rename drivers/{usb = }/phy/phy-omap-usb2.c (88%)
I tried to apply this to my USB branch, but it fails.
Kishon, you were going to refresh this patch series, right? Please do,
because as-is, I can't take it.
thanks,
greg k-h
--
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: Booting recent mainline on omap5-uevm
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Wednesday, September 25, 2013 11:37 AM
On 09/25/2013 10:02 AM, Santosh Shilimkar wrote:
On Tuesday 24 September 2013 07:59 PM, Paul Zimmerman wrote:
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Tuesday, September 24, 2013 4:48 PM
On 09/24/2013 05:24 PM, Santosh Shilimkar wrote:
On Tuesday 24 September 2013 04:30 PM, Paul Zimmerman wrote:
From: Paul Zimmerman
Sent: Tuesday, September 24, 2013 1:21 PM
Hi,
I have an OMAP5432 uEVM which I cannot get to boot with recent mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board
(v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread: http://marc.info/?l=fedora-armm=137717811815777
and
Wrong link, should have been
http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox
data} which
added hwmod data but DT data for mailbox is missing. Reverting that makes
things work. Looks like mailbox dt patches missed the last merge window.
I will be respinning the mailbox DT series very soon targeting 3.13, so
should not be an issue when OMAP5 boot is supported directly on mainline.
That's good info, but unfortunately it didn't work for me. I must have a
different problem, maybe I need a newer version of u-boot.
So there is no README or wiki that explains how to get Linux to boot on
this board? Is there perhaps a prebuilt SD card image somewhere with a
recent kernel that I can grab?
You don't need anything special as such. Just pull the latest mainline
denx u-boot build it for 'omap5_uevm' and update your boot-loaders.
FYI, I was able to boot using the branch posted by Santosh just fine. I
used v2013.07 u-boot. The boot traces show up about 30~45 seconds after
you see the trace Starting kernel
For using a rootfs from MMC, enable the following in menuconfig:
Device Drivers - Multifunction device drivers - TI Palmas series chips
Device Drivers - Voltage and Current Regulator Support - TI Palmas
PMIC regulators.
Depending on your u-boot settings, make sure the mmcroot is also set to
/dev/mmcblk1p2.
Hi Suman,
Thanks for trying to help. Unfortunately, updating to v2013.07 u-boot, and
enabling the kernel config items you mentioned, didn't make a difference.
Could you share your boot.scr? I'm still using the one from the TI GLSDK,
but maybe something has changed since the 3.8 kernel? Also, how do you
build your kernel? I'm doing make LOADADDR=0x80008000 uImage because
newer kernels won't build without the LOADADDR= bit.
I guess you TI guys know how all this works, but for an outsider like me
it's not so clear ;)
--
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: [RESEND PATCH v3 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params
On Thu, Sep 26, 2013 at 10:18:26PM +0300, Jyri Sarha wrote: The sysclk rate does not change runtime so it should be initialized at init time. If you want the DT maintainers to review this stuff you probably need to send it to them rather than spam the ASoC maintainers again. signature.asc Description: Digital signature
Re: [PATCH 00/51] DMA mask changes
2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk: This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Huh, I think it was enough to send only 3 patches to the b43-dev@. Like: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks [PATCH 14/51] DMA-API: net: b43: (...) [PATCH 15/51] DMA-API: net: b43legacy: (...) ;) I believe Joe has some nice script for doing it that way. When fixing some coding style / formatting, he sends only related patches to the given ML. -- Rafał -- 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: Booting recent mainline on omap5-uevm
Hi Paul,
Hi,
I have an OMAP5432 uEVM which I cannot get to boot with recent mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board
(v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread: http://marc.info/?l=fedora-armm=137717811815777
and
Wrong link, should have been
http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox
data} which
added hwmod data but DT data for mailbox is missing. Reverting that makes
things work. Looks like mailbox dt patches missed the last merge window.
I will be respinning the mailbox DT series very soon targeting 3.13, so
should not be an issue when OMAP5 boot is supported directly on mainline.
That's good info, but unfortunately it didn't work for me. I must have a
different problem, maybe I need a newer version of u-boot.
So there is no README or wiki that explains how to get Linux to boot on
this board? Is there perhaps a prebuilt SD card image somewhere with a
recent kernel that I can grab?
You don't need anything special as such. Just pull the latest mainline
denx u-boot build it for 'omap5_uevm' and update your boot-loaders.
FYI, I was able to boot using the branch posted by Santosh just fine. I
used v2013.07 u-boot. The boot traces show up about 30~45 seconds after
you see the trace Starting kernel
For using a rootfs from MMC, enable the following in menuconfig:
Device Drivers - Multifunction device drivers - TI Palmas series chips
Device Drivers - Voltage and Current Regulator Support - TI Palmas
PMIC regulators.
Depending on your u-boot settings, make sure the mmcroot is also set to
/dev/mmcblk1p2.
Hi Suman,
Thanks for trying to help. Unfortunately, updating to v2013.07 u-boot, and
enabling the kernel config items you mentioned, didn't make a difference.
Could you share your boot.scr? I'm still using the one from the TI GLSDK,
but maybe something has changed since the 3.8 kernel? Also, how do you
build your kernel? I'm doing make LOADADDR=0x80008000 uImage because
newer kernels won't build without the LOADADDR= bit.
I build the kernel same way as you, and copy the zImage to boot
partition. I am not using any boot.scr, a simple uEnv.txt to override
the boot partition variables, and the default environment otherwise.
My boot log is here, including my uEnv.txt at the end.
http://hastebin.com/yinuxirexu.xml
Hopefully, this should clear out any setup differences..
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.
The above issue is fixed by reading the dmas property from the DT node if it
exists and clearing the bits in the unused channel list if the dma controller
used by any device is EDMA. For this purpose we use the of_* helpers to parse
the arguments in the dmas phandle list.
Also introduced is a minor clean up of a checkpatch error in old code.
Reviewed-by: Sekhar Nori nsek...@ti.com
Reported-by: Balaji T K balaj...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Olof Johansson o...@lixom.net
Cc: Nishanth Menon n...@ti.com
Cc: Pantel Antoniou pa...@antoniou-consulting.com
Cc: Jason Kridner jkrid...@beagleboard.org
Cc: Koen Kooi k...@dominion.thruhere.net
Signed-off-by: Joel Fernandes jo...@ti.com
---
Just resending this patch after discussing with Sekhar and Olof.
AM335x is being booted by many users such as the beaglebone community. DT is
the only boot method available for all these users. EDMA is required for the
operation for many common peripherals in AM335x SoC such as McASP, MMC and
Crypto.
Although EDMA DT nodes are going in only for 3.13, in reality the kernel has
been used for more than a year with EDMA code and out of tree EDMA DTS patches.
Hence though the DT nodes are still not in mainline, this patch can be still be
considered a critical fix as such and it would be great if it could be included
in 3.12-rc release. Thanks.
More details about why this broke an existing feature folks were using:
Previously the DMA resources for platform devices were being populated through
HWMOD, however with the recent clean ups with HWMOD, this data has been moved
to Device tree. The EDMA code though is not aware of this so it fails to fetch
the DMA resources correctly which it needs to prepare the unused channel list
(basically doesn't properly clear the channels that are in use, in the unused
list).
arch/arm/common/edma.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 117f955..8e1a024 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -269,6 +269,11 @@ static const struct edmacc_param dummy_paramset = {
.ccnt = 1,
};
+static const struct of_device_id edma_of_ids[] = {
+ { .compatible = ti,edma3, },
+ {}
+};
+
/*/
static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
@@ -560,14 +565,38 @@ static int reserve_contiguous_slots(int ctlr, unsigned
int id,
static int prepare_unused_channel_list(struct device *dev, void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- int i, ctlr;
+ int i, count, ctlr;
+ struct of_phandle_args dma_spec;
+ if (dev-of_node) {
+ count = of_property_count_strings(dev-of_node, dma-names);
+ if (count 0)
+ return 0;
+ for (i = 0; i count; i++) {
+ if (of_parse_phandle_with_args(dev-of_node, dmas,
+ #dma-cells, i,
+ dma_spec))
+ continue;
+
+ if (!of_match_node(edma_of_ids, dma_spec.np)) {
+ of_node_put(dma_spec.np);
+ continue;
+ }
+
+ clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
+ edma_cc[0]-edma_unused);
+ of_node_put(dma_spec.np);
+ }
+ return 0;
+ }
+
+ /* For non-OF case */
for (i = 0; i pdev-num_resources; i++) {
if ((pdev-resource[i].flags IORESOURCE_DMA)
(int)pdev-resource[i].start = 0) {
ctlr = EDMA_CTLR(pdev-resource[i].start);
clear_bit(EDMA_CHAN_SLOT(pdev-resource[i].start),
- edma_cc[ctlr]-edma_unused);
+ edma_cc[ctlr]-edma_unused);
}
}
@@ -1762,11 +1791,6 @@ static int edma_probe(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id edma_of_ids[] = {
- { .compatible = ti,edma3, },
- {}
-};
-
static struct platform_driver edma_driver = {
.driver = {
.name = edma,
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/25/2013 10:52:44 AM, Måns Rullgård wrote: Rob Landley r...@landley.net writes: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Since when is assembling the instructions correctly, as specified in the arch ref, and not in some other random way a gnuism? If you require current gnome and drop support for older versions (and implicitly all other desktops), people start writing stuff that depends on systemd. It doesn't matter if the feature you abandoned support for the past 10 years of everthing else for wasn't itself provided by systemd. Rob-- 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: new binutils needed for arm in 3.12-rc1
Rob Landley r...@landley.net writes: On 09/25/2013 10:52:44 AM, Måns Rullgård wrote: Rob Landley r...@landley.net writes: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Since when is assembling the instructions correctly, as specified in the arch ref, and not in some other random way a gnuism? If you require current gnome and drop support for older versions (and implicitly all other desktops), people start writing stuff that depends on systemd. It doesn't matter if the feature you abandoned support for the past 10 years of everthing else for wasn't itself provided by systemd. Are you saying current binutils depends on gnome and/or systemd? -- Måns Rullgård m...@mansr.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: new binutils needed for arm in 3.12-rc1
On 09/25/2013 11:13:17 AM, Nicolas Pitre wrote: On Wed, 25 Sep 2013, Rob Landley wrote: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Gnuism? Let me quote the ARM ARchitecture Reference Manual, version 7 revision C, section A8.8.44 (sorry for the whitespace dammage): Globally changing the binutils requirement for all architectures, as the doc patch at the start of this thread proposed doing, would mean gnuisms in common code (ext2 and such) wouldn't get caught, giving llvm and pcc and such a moving target when trying to build the kernel with non-gnu toolchains. That's what I meant by gnuisms breeding. So what's the link with the above and your issue with GPLv3, besides the fact that the last binutils version to have been released under the GPLv2 is defficient? I apparently wasn't clear. The new instructions aren't gnuisms. The lack of widespread regression testing for armv5l and such would allow introduction of nonportable constructs in a larger context. (The fact that armv7 could apparently build fine for ~7 years with binutils 2.18 through 2.21, and now it's suddenly can't Because Reasons is kinda silly, but not really a big deal. That, I can patch my toolchain.) It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. So you prefer I come up with the reversion patches locally and _not_ send them upstream? Sort of. And I'm suggesting you patch your binutils rather than the kernel. I had this misidentified as a global arm problem and not specific to arm7l. If armv5l still still builds with the old toolchains, it's not a big deal. Given you're not upgrading your binutils anymore that means you'll have to apply that patch only once instead of having to apply it to every kernel upgrade. Indeed. Patching my own toolchain isn't really a problem. My objection was to the Documentation patch telling the world at large that for all targets, older binutils aren't supported even on x86. That was worth pushing back against. I don't indend to use old gcc/binutils versions forever, I just want to be able to use them until I can replace them with llvm or similar. Rob -- 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: new binutils needed for arm in 3.12-rc1
On 09/25/2013 03:49:07 PM, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: On Wed, Sep 25, 2013 at 10:23:06AM -0500, Rob Landley wrote: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. So you prefer I come up with the reversion patches locally and _not_ send them upstream? This is a silly attitude. What you're effectively saying is that we are never allowed to use any future ARM instructions in any Linux kernel because that might break your precious assembler. I've got news for you. We're *not* going to listen to that argument. END OF DISCUSSION (everything else is just a waste of time.) Who am I to argue with capital letters? I fully agree. Actually, I thought this was an armv5l regression. (My objection was to requiring a newer toolchain for architectures that built fine under the old one. My attention was attracted by the proposed patch to Documentation/changes with a global updated for required binutils version.) I've since had a chance to confirm the armv5 build break I saw was just normal mid-rc1 noise (since fixed) and this set of patches just applies to armv7, which already required a newer binutils, so objection withdrawn. Rob-- 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 v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Nishanth Menon n...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Cc: Jason Kridner jkrid...@beagleboard.org Cc: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel Fernandes jo...@ti.com --- Just resending this patch after discussing with Sekhar and Olof. Actually, the patch you talked to me about was v3 of this. It seems that you have reposted v6 but labelled it v3. This is very confusing. AM335x is being booted by many users such as the beaglebone community. DT is the only boot method available for all these users. EDMA is required for the operation for many common peripherals in AM335x SoC such as McASP, MMC and Crypto. Although EDMA DT nodes are going in only for 3.13, in reality the kernel has been used for more than a year with EDMA code and out of tree EDMA DTS patches. Hence though the DT nodes are still not in mainline, this patch can be still be considered a critical fix as such and it would be great if it could be included in 3.12-rc release. Thanks. This is really the root of this problem. If you sit on code out of tree for a year, and something breaks that we couldn't even have detected since we didn't have the out-of-tree pieces. We'll help you the first few times (such as now) but we will eventually stop caring. If I was in a worse mood, then I'd just say that since your users already has to have out-of-tree code to even use this functionality, they could just add this fix on top of that stack of patches. But I'm in a slightly better mood than that and I'll pick it up this time. :) More details about why this broke an existing feature folks were using: Previously the DMA resources for platform devices were being populated through HWMOD, however with the recent clean ups with HWMOD, this data has been moved to Device tree. The EDMA code though is not aware of this so it fails to fetch the DMA resources correctly which it needs to prepare the unused channel list (basically doesn't properly clear the channels that are in use, in the unused list). So that we can learn for next time: What should we (as in us maintainers and you TI) have done differently to avoid this? -Olof -- 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 v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/24/2013 01:58 AM, Javier Martinez Canillas wrote: The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another caller won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. FWIW, the concept of this patch, Acked-by: Stephen Warren swar...@nvidia.com I didn't review the code; just skimmed it to see where the new functionality was implemented. -- 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
Solved: Booting recent mainline on omap5-uevm
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Thursday, September 26, 2013 1:36 PM
I have an OMAP5432 uEVM which I cannot get to boot with recent
mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board
(v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread:
http://marc.info/?l=fedora-armm=137717811815777 and
Wrong link, should have been
http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox
data} which
added hwmod data but DT data for mailbox is missing. Reverting that
makes
things work. Looks like mailbox dt patches missed the last merge
window.
I will be respinning the mailbox DT series very soon targeting 3.13, so
should not be an issue when OMAP5 boot is supported directly on
mainline.
That's good info, but unfortunately it didn't work for me. I must have a
different problem, maybe I need a newer version of u-boot.
So there is no README or wiki that explains how to get Linux to boot on
this board? Is there perhaps a prebuilt SD card image somewhere with a
recent kernel that I can grab?
You don't need anything special as such. Just pull the latest mainline
denx u-boot build it for 'omap5_uevm' and update your boot-loaders.
FYI, I was able to boot using the branch posted by Santosh just fine. I
used v2013.07 u-boot. The boot traces show up about 30~45 seconds after
you see the trace Starting kernel
For using a rootfs from MMC, enable the following in menuconfig:
Device Drivers - Multifunction device drivers - TI Palmas series chips
Device Drivers - Voltage and Current Regulator Support - TI Palmas
PMIC regulators.
Depending on your u-boot settings, make sure the mmcroot is also set to
/dev/mmcblk1p2.
Hi Suman,
Thanks for trying to help. Unfortunately, updating to v2013.07 u-boot, and
enabling the kernel config items you mentioned, didn't make a difference.
Could you share your boot.scr? I'm still using the one from the TI GLSDK,
but maybe something has changed since the 3.8 kernel? Also, how do you
build your kernel? I'm doing make LOADADDR=0x80008000 uImage because
newer kernels won't build without the LOADADDR= bit.
I build the kernel same way as you, and copy the zImage to boot
partition. I am not using any boot.scr, a simple uEnv.txt to override
the boot partition variables, and the default environment otherwise.
My boot log is here, including my uEnv.txt at the end.
http://hastebin.com/yinuxirexu.xml
Hopefully, this should clear out any setup differences..
Thanks Suman!
Using your info I was able to get the board to boot. The keys were
1) building the kernel with make zImage instead of make uImage and
2) removing boot.scr and adding uEnv.txt.
I added a third line to your uEnv.txt, so I don't have to break into
u-boot and type setenv mmcroot /dev/mmcblk1p2 rw:
bootdir=
bootpart=0:1
mmcroot=/dev/mmcblk1p2 rw
Or I suppose you could add that to the kernel command line in the kernel
config.
I'm seeing several stack dumps during the boot, with messages like
division by 0 in the kernel, but I suppose that has nothing to do with
my boot problems. And it does boot to the login: prompt on the serial
console.
Thanks 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
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 09/26/2013 06:13 PM, Olof Johansson wrote: On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Nishanth Menon n...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Cc: Jason Kridner jkrid...@beagleboard.org Cc: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel Fernandes jo...@ti.com --- Just resending this patch after discussing with Sekhar and Olof. Actually, the patch you talked to me about was v3 of this. It seems that you have reposted v6 but labelled it v3. This is very confusing. Sorry about this. :-( This is indeed v6. AM335x is being booted by many users such as the beaglebone community. DT is the only boot method available for all these users. EDMA is required for the operation for many common peripherals in AM335x SoC such as McASP, MMC and Crypto. Although EDMA DT nodes are going in only for 3.13, in reality the kernel has been used for more than a year with EDMA code and out of tree EDMA DTS patches. Hence though the DT nodes are still not in mainline, this patch can be still be considered a critical fix as such and it would be great if it could be included in 3.12-rc release. Thanks. This is really the root of this problem. If you sit on code out of tree for a year, and something breaks that we couldn't even have detected since we didn't have the out-of-tree pieces. We'll help you the first few times (such as now) but we will eventually stop caring. When I started looking at EDMA in June, I noticed that a lot had already been merged. EDMA DMA Engine driver itself was merged last year, no worries there. but the long pending list of fixes to be made to the driver had to written and rewritten multiple times which took a long time. Due to this, the EDMA device tree entries could not be merged in fear that doing so would cause problems such as MMC/SD corruption etc. If I was in a worse mood, then I'd just say that since your users already has to have out-of-tree code to even use this functionality, they could just add this fix on top of that stack of patches. But I'm in a slightly better mood than that and I'll pick it up this time. :) Thank you! :) More details about why this broke an existing feature folks were using: Previously the DMA resources for platform devices were being populated through HWMOD, however with the recent clean ups with HWMOD, this data has been moved to Device tree. The EDMA code though is not aware of this so it fails to fetch the DMA resources correctly which it needs to prepare the unused channel list (basically doesn't properly clear the channels that are in use, in the unused list). So that we can learn for next time: What should we (as in us maintainers and you TI) have done differently to avoid this? I think a little on both sides can be improved. For TI, a bit more work toward explaining patches better in change logs so that maintainers understand and are willing to help to get the code upstream would help. A lot of improvement to internal policies have been made for developing on upstream, and that's certainly a good thing but there's still more room for improvement. For maintainers, EDMA code would have been kept breathing all these months (atleast 8 months) if those temporary fixes mentioned above would have been merged into the kernel instead of not applied. With those fixes in place, dts could have been enabled and EDMA would be fully working all these months. This would have certainly made things a lot easier. Rewriting stuff the right way is OK but if it is a _lot_ of effort, then to keep things alive, merging stuff for now specially if they are one-liners could be made acceptable. EDMA fixes have now been written the right way, so those temporary fixes are no longer needed :) but it certainly took a long time to do it the right way during which things were dead. Only thing pending for working EDMA now is the dts patches which are already in Benoit's for-3.13 tree and this patch that you're picking up. Thanks Olof for your help! :) regards, -Joel -- 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 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
The code sequence:
isp-raw_dmamask = DMA_BIT_MASK(32);
isp-dev-dma_mask = isp-raw_dmamask;
isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.c |6 +++---
drivers/media/platform/omap3isp/isp.h |3 ---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index df3a0ec..1c36080 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
isp-pdata = pdata;
isp-ref_count = 0;
- isp-raw_dmamask = DMA_BIT_MASK(32);
- isp-dev-dma_mask = isp-raw_dmamask;
- isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(isp-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
platform_set_drvdata(pdev, isp);
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index cd3eff4..ce65d3a 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -152,7 +152,6 @@ struct isp_xclk {
* @mmio_base_phys: Array with physical L4 bus addresses for ISP register
* regions.
* @mmio_size: Array with ISP register regions size in bytes.
- * @raw_dmamask: Raw DMA mask
* @stat_lock: Spinlock for handling statistics
* @isp_mutex: Mutex for serializing requests to ISP.
* @crashed: Bitmask of crashed entities (indexed by entity ID)
@@ -190,8 +189,6 @@ struct isp_device {
unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
- u64 raw_dmamask;
-
/* ISP Obj */
spinlock_t stat_lock; /* common lock for statistic drivers */
struct mutex isp_mutex; /* For handling ref_count field */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Solved: Booting recent mainline on omap5-uevm
On 09/26/2013 06:44 PM, Paul Zimmerman wrote:
From: Suman Anna [mailto:s-a...@ti.com]
Sent: Thursday, September 26, 2013 1:36 PM
I have an OMAP5432 uEVM which I cannot get to boot with recent
mainline
(tried 3.11 and 3.12-rc1). I have the TI GLSDK for this board
(v6.0.0.7),
which comes with 3.8.4 which works fine.
I found this thread:
http://marc.info/?l=fedora-armm=137717811815777 and
Wrong link, should have been
http://marc.info/?l=linux-omapm=137515583214350.
Its because of commit 03ab349ec{ARM: OMAP5: hwmod data: Add mailbox
data} which
added hwmod data but DT data for mailbox is missing. Reverting that
makes
things work. Looks like mailbox dt patches missed the last merge
window.
I will be respinning the mailbox DT series very soon targeting 3.13, so
should not be an issue when OMAP5 boot is supported directly on
mainline.
That's good info, but unfortunately it didn't work for me. I must have a
different problem, maybe I need a newer version of u-boot.
So there is no README or wiki that explains how to get Linux to boot on
this board? Is there perhaps a prebuilt SD card image somewhere with a
recent kernel that I can grab?
You don't need anything special as such. Just pull the latest mainline
denx u-boot build it for 'omap5_uevm' and update your boot-loaders.
FYI, I was able to boot using the branch posted by Santosh just fine. I
used v2013.07 u-boot. The boot traces show up about 30~45 seconds after
you see the trace Starting kernel
For using a rootfs from MMC, enable the following in menuconfig:
Device Drivers - Multifunction device drivers - TI Palmas series chips
Device Drivers - Voltage and Current Regulator Support - TI Palmas
PMIC regulators.
Depending on your u-boot settings, make sure the mmcroot is also set to
/dev/mmcblk1p2.
Hi Suman,
Thanks for trying to help. Unfortunately, updating to v2013.07 u-boot, and
enabling the kernel config items you mentioned, didn't make a difference.
Could you share your boot.scr? I'm still using the one from the TI GLSDK,
but maybe something has changed since the 3.8 kernel? Also, how do you
build your kernel? I'm doing make LOADADDR=0x80008000 uImage because
newer kernels won't build without the LOADADDR= bit.
I build the kernel same way as you, and copy the zImage to boot
partition. I am not using any boot.scr, a simple uEnv.txt to override
the boot partition variables, and the default environment otherwise.
My boot log is here, including my uEnv.txt at the end.
http://hastebin.com/yinuxirexu.xml
Hopefully, this should clear out any setup differences..
Thanks Suman!
Using your info I was able to get the board to boot.
Glad I could help..
I added a third line to your uEnv.txt, so I don't have to break into
u-boot and type setenv mmcroot /dev/mmcblk1p2 rw:
bootdir=
bootpart=0:1
mmcroot=/dev/mmcblk1p2 rw
Or I suppose you could add that to the kernel command line in the kernel
config.
The uEnv.txt approach is good, since you can use the same image on other
boards without resorting to other changes in environment for them.
I'm seeing several stack dumps during the boot, with messages like
division by 0 in the kernel, but I suppose that has nothing to do with
my boot problems. And it does boot to the login: prompt on the serial
console.
Yeah, those I believe are related to the ABE and USB DPLL locking (or
lack of) issues.
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 16/18] arm: dts: add omap5 CORE thermal data
This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5-core-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 000..3e9dc00
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+core_thermal: core_thermal {
+ polling-delay-passive = 250; /* milliseconds */
+ polling-delay = 1000; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = bandgap 2;
+
+ trips {
+ core_crit: core_crit {
+ temperature = 125000; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv4 13/18] arm: dts: add cooling properties on omap4430 cpu node
OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: Benoît Cousson bcous...@baylibre.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/boot/dts/omap443x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index e9c97d6..930ab47 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,11 @@ 1008000 1375000 ; clock-latency = 30; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = 0; + cooling-max-level = 3; + #cooling-cells = 2; /* min followed by max */ }; }; -- 1.8.2.1.342.gfa7285d -- 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
[PATCHv4 18/18] arm: dts: add cooling properties on omap5 cpu node
OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.
This patch adds the required cooling device properties
so that cpufreq-cpu0 driver loads the cooling device.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 187cb71..a35cd61 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -37,6 +37,9 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
+
+ /* cooling options */
+ #cooling-cells = 2; /* min followed by max */
};
cpu@1 {
device_type = cpu;
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv4 11/18] arm: dts: add omap4430 thermal data
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
- cpu@0 {
+ cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points =
/* kHzuV */
@@ -25,9 +25,15 @@
};
};
- bandgap {
+ thermal-zones{
+ #include omap4-cpu-thermal.dtsi
+ };
+
+ bandgap: bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+
+ #thermal-sensor-cells = 0;
};
};
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv4 17/18] arm: dts: add omap5 thermal data
This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..187cb71 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,7 +33,7 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
@@ -45,6 +45,12 @@
};
};
+ thermal-zones {
+ #include omap4-cpu-thermal.dtsi
+ #include omap5-gpu-thermal.dtsi
+ #include omap5-core-thermal.dtsi
+ };
+
timer {
compatible = arm,armv7-timer;
/* PPI secure/nonsecure IRQ */
@@ -705,13 +711,15 @@
};
};
- bandgap@4a0021e0 {
+ bandgap: bandgap@4a0021e0 {
reg = 0x4a0021e0 0xc
0x4a00232c 0xc
0x4a002380 0x2c
0x4a0023C0 0x3c;
interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
compatible = ti,omap5430-bandgap;
+
+ #thermal-sensor-cells = 1;
};
};
};
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv4 14/18] arm: dts: add cooling properties on omap4460 cpu node
OMAP4460 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: Benoît Cousson bcous...@baylibre.com Cc: Tony Lindgren t...@atomide.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Ian Campbell ian.campb...@citrix.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/boot/dts/omap4460.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi index 4d93aba..dc22719 100644 --- a/arch/arm/boot/dts/omap4460.dtsi +++ b/arch/arm/boot/dts/omap4460.dtsi @@ -20,6 +20,11 @@ 92 1313000 ; clock-latency = 30; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = 0; + cooling-max-level = 2; + #cooling-cells = 2; /* min followed by max */ }; }; -- 1.8.2.1.342.gfa7285d -- 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
[PATCHv4 15/18] arm: dts: add omap5 GPU thermal data
This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 000..8941c8e
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+gpu_thermal: gpu_thermal {
+ polling-delay-passive = 250; /* milliseconds */
+ polling-delay = 1000; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = bandgap 1;
+
+ trips {
+ gpu_crit: gpu_crit {
+ temperature = 125000; /* milliCelsius */
+ hysteresis = 2000; /* milliCelsius */
+ type = THERMAL_TRIP_CRITICAL;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv4 10/18] arm: dts: add omap4 CPU thermal data
This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41
1 file changed, 41 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 000..65a6deb
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/thermal/thermal.h
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = 250; /* milliseconds */
+ polling-delay = 1000; /* milliseconds */
+
+ /* sensor ID */
+thermal-sensors = bandgap 0;
+
+trips {
+cpu_alert0: cpu_alert {
+temperature = 10; /* millicelsius */
+hysteresis = 2000; /* millicelsius */
+type = THERMAL_TRIP_PASSIVE;
+};
+cpu_crit: cpu_crit {
+temperature = 125000; /* millicelsius */
+hysteresis = 2000; /* millicelsius */
+type = THERMAL_TRIP_CRITICAL;
+};
+};
+
+ cooling-maps {
+ map0 {
+ trip = cpu_alert0;
+ cooling-device =
+ cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
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
[PATCHv4 12/18] arm: dts: add omap4460 thermal data
This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..4d93aba 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
- cpu@0 {
+ cpu0: cpu@0 {
operating-points =
/* kHzuV */
35 1025000
@@ -30,12 +30,18 @@
ti,hwmods = debugss;
};
- bandgap {
+ thermal-zones{
+ #include omap4-cpu-thermal.dtsi
+ };
+
+ bandgap: bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4
0x4a002378 0x18;
compatible = ti,omap4460-bandgap;
interrupts = 0 126 IRQ_TYPE_LEVEL_HIGH; /* talert */
gpios = gpio3 22 0; /* tshut */
+
+ #thermal-sensor-cells = 0;
};
};
--
1.8.2.1.342.gfa7285d
--
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
