Re: [PATCH 1/4] ARM: dts: Add support for OMAP4 Variscite OM44 family
On 30/04/14 04:24, Joachim Eastwood wrote: > Do you plan to push the patch that add hpd-gpios to the > "hdmi-connector" for 3.16? (nodes for my board below) > https://patchwork.kernel.org/patch/4006021/ > > Also in the patch set I am using your DT bindings for "panel-dpi". See > patch [2 of 4] for nodes. > https://patchwork.kernel.org/patch/4047241/ > > Will this patch be upstream in 3.16? Yes, they are both planned to be in 3.16. The patches are still under work, though. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On Tue, Apr 29, 2014 at 10:17:01AM -0600, Stephen Warren wrote: > On 04/28/2014 06:02 PM, Simon Horman wrote: > > On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: > >> Since we now automatically enable early BRESP in core L2C-310 code when > >> we detect a Cortex-A9, we don't need platforms/SoCs to set this bit > >> explicitly. Instead, they should seek to preserve the value of bit 30 > >> in the auxiliary control register. > >> > >> Acked-by: Tony Lindgren > >> Signed-off-by: Russell King > > > > I would prefer if this patch was broken out into individual patches > > for each board or SoC file and that they were then picked up > > by their respective platform maintainers. > > > > Likewise for patch 66/97. Although it is only for shmobile > > I would prefer it broken out. > > There are far too many dependencies in this series to break out the > board file patches to be merged separately; it'd take either a whole > bunch of kernel releases to merge it all that way, or a twisty maze of > tiny topic branches cross-merged all over the place. Neither option is > realistic. Understood, that seems reasonable to me. For the shmobile portions this patch and 66/97. Acked-by: Simon Horman -- 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 06/23] ARM: OMAP: add OMAP5 DSI muxing
On 29/04/14 20:38, Tony Lindgren wrote: > * Tomi Valkeinen [140429 09:33]: >> On 29/04/14 19:19, Tomi Valkeinen wrote: >>> On 29/04/14 18:05, Tony Lindgren wrote: >>> > omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives > a raw regmap to its memory area, the driver needs to know about the OMAP > control registers to use it. That would be probably best set up the same way we have already set up for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can access it using regmap, see how drivers/regulator/pbias-regulator.c sets up the pbias regulator with regmap for MMC. >>> >>> Right, but it means that the driver will contain platform specific code >>> for all the omap revisions it supports. Isn't that wrong? >>> >>> I already have a patch for DSI that uses the syscon-method, and it works >>> fine. But it's quite ugly, imo, to fiddle with the OMAP control >>> registers in a driver. > > Anything using the system control module registers should be a separate > driver. And it should ideally be implemeting some Linux generic framework > that the consumer driver can then use. That leaves out the need to export > custom functions. Ok. > I guess we don't have a PHY framework for displays though, so how about > just a separate minimal driver under drivers/video/omap2 that uses the > syscon? Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register is not in the DSI PHY block, but in the control module, and it is used to enable/disable the pins (for omap4/5) and to set pull up/down for the pins (only for omap4). Oddly, for omap5, there's also a normal padconfig register for the DSI pins, but not so for omap4. To me it looks like a pad config register. I don't know why there's a separate odd register for it and it's not using the normal padconfig system. I'd like to use the pinctrl framework for it, but the pinctrl-single cannot handle such a funny register. So, if "Anything using the system control module registers should be a separate driver", then I guess I need to write a pinctrl driver for this single register? >> Oh, also, if I do that, I need to know both the SoC version and the DSS >> version in the driver. > > Don't you get all you need in the compatible string? Something like > compatible ti,dss-phy-omap5? We do use different compatible strings for different major versions of the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could be used on some other SoC, with different control stuff. We could use separate compatible string for each SoC that uses DSS, but then we're really encoding the SoC version into the compatible string, not DSS version. Of course, if there will be a separate driver managing the CONTROL_DSIPHY register, then that one should use compatible string specific to the SoC, as it's not a DSS driver at all. Tomi signature.asc Description: OpenPGP digital signature
Re: [patch V2 0/6] dma: edma: Provide granular residue accounting
On Tue, Apr 29, 2014 at 11:25:02PM -0500, Joel Fernandes wrote: > On 04/29/2014 03:46 AM, Vinod Koul wrote: > [..] > > commit 770f0f3a20188b7e17db2790803b9da925dc0b94 > > Author: Thomas Gleixner > > Date: Mon Apr 28 10:49:43 2014 + > > > > dmaengine: edma: Make reading the position of active channels work > > > > As Joel pointed out, edma_read_position() uses memcpy_fromio() to read > > the parameter ram. That's not synchronized with the internal update as > > it does a byte by byte copy. We need to do a 32bit read to get a > > consistent value. > > > > Further reading destination and source is pointless. In DEV_TO_MEM > > transfers we are only interested in the destination, in MEM_TO_DEV we > > care about the source. In MEM_TO_MEM it really does not matter which > > one you read. > > > > Simple solution: Remove the pointers, select dest/source via a bool > > and return the read value. > > > > Remove the export of this function while at it. The only potential > > user is the dmaengine and that's always builtin. > > > > Signed-off-by: Thomas Gleixner > > > > You s-o-b missing in this one, also ack from Sekhar missing. Do you want to > > redo > > this or prefer me to cherry-pick patches adding acks and your s-o-b, since I > > already fetched your branch > > > > Either way is fine with me... > > > > If its Ok with you, it would great if you could add my Ack and Sob. > Thanks a lot. Let me know if you'd want me to do anything else here. Done, The changes are getting pushed, pls do verify -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch V2 0/6] dma: edma: Provide granular residue accounting
On 04/29/2014 03:46 AM, Vinod Koul wrote: [..] > commit 770f0f3a20188b7e17db2790803b9da925dc0b94 > Author: Thomas Gleixner > Date: Mon Apr 28 10:49:43 2014 + > > dmaengine: edma: Make reading the position of active channels work > > As Joel pointed out, edma_read_position() uses memcpy_fromio() to read > the parameter ram. That's not synchronized with the internal update as > it does a byte by byte copy. We need to do a 32bit read to get a > consistent value. > > Further reading destination and source is pointless. In DEV_TO_MEM > transfers we are only interested in the destination, in MEM_TO_DEV we > care about the source. In MEM_TO_MEM it really does not matter which > one you read. > > Simple solution: Remove the pointers, select dest/source via a bool > and return the read value. > > Remove the export of this function while at it. The only potential > user is the dmaengine and that's always builtin. > > Signed-off-by: Thomas Gleixner > > You s-o-b missing in this one, also ack from Sekhar missing. Do you want to > redo > this or prefer me to cherry-pick patches adding acks and your s-o-b, since I > already fetched your branch > > Either way is fine with me... > If its Ok with you, it would great if you could add my Ack and Sob. Thanks a lot. Let me know if you'd want me to do anything else here. 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] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On 04/29/2014 01:31 PM, Dave Martin wrote: > On Tue, Apr 29, 2014 at 05:36:30PM +0100, Joel Fernandes wrote: > > [...] > Sorry what I meant is, say its of Type function. What tells the firmware to switch to THUMB? What's typically done is a boot address register is written by the kernel, and the firmware jumps to it after WFE. >>> >>> Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker >>> for x to have the Thumb bit set if the code is Thumb. >>> >>> This means that any reference the linker fixes up for that symbol >>> will have the Thumb bit set appropriately. This applies to any kind >>> of reference, so code in another file that takes the address of the >>> symbol and then passes that address to the firmware should result in the >>> firmware getting an address with the Thumb bit. >>> >>> From the firmware's point of view it just gets a raw address, but >>> the Thumb bit will now be set. The firmware still needs to handle >>> this correctly when jumping, but from the look of the code this may >>> already work on omap3/4. It would be interesting to know whether it >>> works on omap5. >> >> Thanks a lot for the explanation. That makes perfect sense. I will try it >> and let you know if it works on OMAP5. > > ARM/thumb interworking making perfect sense? I'll have to frame that > and put it on the wall :) > > objdump and nm conveniently mask off the Thumb bit from all function > addresses they print out, but if you show the symbols using readelf > instead you'll see addresses with bit 0 set for Thumb functions. > > It's possible that the firmware still doesn't handle branching to Thumb > correctly, but if it does it would be nice to remove the requirement to > build an odd piece of a Thumb-2 kernel in ARM. Sure, it works great! thanks, I sent out a patch that applies on top of the first one. Thanks for spotting it. 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
[PATCH] ARM: OMAP5: Redo THUMB mode switch on secondary CPU
Here's a redo of the patch [1] that effectively does the same thing but is the right way to do things by using ENDPROC instead. The firmware correctly switches to THUMB before entry. The patch applies ontop of the earlier patch [1]. [1] https://lkml.org/lkml/2014/4/22/1044 Suggested-by: Dave Martin Cc: Dave Martin Cc: Santosh Shilimkar Cc: Russell King Cc: Nishanth Menon Cc: Tony Lindgren Signed-off-by: Joel Fernandes --- Tony, the earlier patch went into your fixes, and can remain. This patch is just a simple redo of the same and can go in for v3.16, no problem. Thanks. arch/arm/mach-omap2/omap-headsmp.S |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 1809dce..bf36f26 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -31,10 +31,6 @@ * register AuxCoreBoot0. */ ENTRY(omap5_secondary_startup) -.arm -THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode. -THUMB( bx r9 ) @ If this is a Thumb-2 kernel, -THUMB( .thumb ) @ switch to Thumb now. wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] mov r0, r0, lsr #5 @@ -43,7 +39,7 @@ wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 cmp r0, r4 bne wait b secondary_startup -END(omap5_secondary_startup) +ENDPROC(omap5_secondary_startup) /* * OMAP4 specific entry point for secondary CPU to jump from ROM * code. This routine also provides a holding flag into which -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/5] mmc: omap_hsmmc: Enable SDIO interrupt
Minor nit...
On 04/28/2014 02:40 AM, Andreas Fenkart wrote:
[..]
> /* Do not initialize card-specific things if the power is off */
> if (host->power_mode == MMC_POWER_OFF)
> @@ -1117,8 +1138,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);
> @@ -1127,6 +1152,23 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
> *dev_id)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t omap_hsmmc_wake_irq(int irq, void *dev_id)
> +{
> + struct omap_hsmmc_host *host = dev_id;
> + unsigned long flags;
> +
> + /* cirq is level triggered, disable to avoid infinite loop */
> + spin_lock_irqsave(&host->irq_lock, flags);
Do you need to save restore flags here? IRQ is already disabled since
you're in hard IRQ context so spin_lock() seems sufficient.
> + if (host->flags & HSMMC_WAKE_IRQ_ENABLED) {
> + disable_irq_nosync(host->wake_irq);
> + host->flags &= ~HSMMC_WAKE_IRQ_ENABLED;
> + }
> + spin_unlock_irqrestore(&host->irq_lock, flags);
spin_unlock() seems sufficient.
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 v10 1/5] mmc: omap_hsmmc: Enable SDIO interrupt
Minor nit...
On 04/28/2014 02:40 AM, Andreas Fenkart wrote:
[..]
> /* Do not initialize card-specific things if the power is off */
> if (host->power_mode == MMC_POWER_OFF)
> @@ -1117,8 +1138,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);
> @@ -1127,6 +1152,23 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
> *dev_id)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t omap_hsmmc_wake_irq(int irq, void *dev_id)
> +{
> + struct omap_hsmmc_host *host = dev_id;
> + unsigned long flags;
> +
> + /* cirq is level triggered, disable to avoid infinite loop */
> + spin_lock_irqsave(&host->irq_lock, flags);
Do you need to save restore flags here? IRQ is already disabled since
you're in hard IRQ context so spin_lock() seems sufficient.
> + if (host->flags & HSMMC_WAKE_IRQ_ENABLED) {
> + disable_irq_nosync(host->wake_irq);
> + host->flags &= ~HSMMC_WAKE_IRQ_ENABLED;
> + }
> + spin_unlock_irqrestore(&host->irq_lock, flags);
spin_unlock() seems sufficient.
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 1/4] ARM: dts: Add support for OMAP4 Variscite OM44 family
On 18 April 2014 17:10, Joachim Eastwood wrote:
> Add support for VAR-SOM-OM44[1] SODIMM system on module from Variscite. SoM
> features a OMAP4460, 1GB RAM, Gigabit Ethernet (LAN7500) and optional WLAN/BT.
>
> Also add support for VAR-STK-OM44 development board from Variscite. This kit
> features a VAR-SOM-OM44 and the carrier board VAR-OM44CustomBoard[2]. The
> VAR-STK-OM44 is the same as VAR-DVK-OM44 but without the LCD display.
>
> omap4-var-stk-om44.dts replace the old and very limited omap4-var-som.dts.
>
> [1]
> http://www.variscite.com/products/system-on-module-som/cortex-a9/var-som-om44-cpu-ti-omap-4-omap4460
> [2]
> http://www.variscite.com/products/single-board-computers/var-om44customboard
>
> Signed-off-by: Joachim Eastwood
> ---
Tomi,
Do you plan to push the patch that add hpd-gpios to the
"hdmi-connector" for 3.16? (nodes for my board below)
https://patchwork.kernel.org/patch/4006021/
Also in the patch set I am using your DT bindings for "panel-dpi". See
patch [2 of 4] for nodes.
https://patchwork.kernel.org/patch/4047241/
Will this patch be upstream in 3.16?
As I am about to send out a new version of this patch set it would be
nice to know if I need to split out the display stuff, for later
inclusion, or if it can go in as it is.
regards
Joachim Eastwood
> + hdmi0: connector@0 {
> + compatible = "hdmi-connector";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_hpd_pins>;
> + label = "hdmi";
> + type = "a";
> +
> + hpd-gpios = <&gpio2 31 GPIO_ACTIVE_HIGH>; /* gpio_63 */
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_out>;
> + };
> + };
> + };
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
On 30 April 2014 01:52, Tony Lindgren wrote:
> Looks like quite a few omaps have sharp ls037v7dw01 that's configured
> as various panel dpi entries for whatever legacy reasons. For device
> tree based support, let's just configure these properly for panel
> ls037v7dw01 instead of panel dpi.
>
> This patch creates a common file for panel ls037v7dw01, and makes
> boards ldp and omap3-evm to use it. The panel for ldp is configured
> in the qvga mode and omap3-evm panel in vga mode.
>
> The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
> controller for the omaps, so let's add a basic configuration for
> the touchscreen also using the default values.
>
> Note that we can now remove the regulator-name = "vdds_dsi"
> entry for ldp, that's no longer needed as we have the entry
> for vdds_dsi-supply = <&vpll2>.
>
> Signed-off-by: Tony Lindgren
> ---
> .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82
> ++
> arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +
> arch/arm/boot/dts/omap3-evm-common.dtsi| 47 +
> arch/arm/boot/dts/omap3-ldp.dts| 31 ++--
> 4 files changed, 205 insertions(+), 5 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> index 0abe986..50fdac9 100644
> --- a/arch/arm/boot/dts/omap3-ldp.dts
> +++ b/arch/arm/boot/dts/omap3-ldp.dts
> @@ -164,6 +164,7 @@
>
> #include "twl4030.dtsi"
> #include "twl4030_omap3.dtsi"
> +#include "omap-panel-sharp-ls037v7dw01.dtsi"
>
> &i2c2 {
> clock-frequency = <40>;
> @@ -173,6 +174,31 @@
> clock-frequency = <40>;
> };
>
> +&lcd_3v3 {
> + gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +};
> +
> +&lcd0 {
> + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
enable-gpios ?
> +0 /* lcd LR */
> +0 /* lcd UD */
> +0>;/* lcd INI */
> +};
regards
Joachim Eastwood
--
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 08/11] ARM: dts: am33xx: Add prcm_resets node
* Arnd Bergmann [140429 13:35]:
> On Tuesday 29 April 2014 15:19:47 Dan Murphy wrote:
> > + * AM33xx reset index for PRCM Module
> > + *
> > + * Copyright 2014 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.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_RESET_TI_AM33XX_H
> > +#define _DT_BINDINGS_RESET_TI_AM33XX_H
> > +
> > +#define RESET_DEVICE_RESET 0
> > +#define RESET_GFX_RESET1
> > +#define RESET_PER_RESET2
> > +
> > +#endif
>
> Interfaces like this should only be used if you can't use hardware
> numbers, in general. If these numbers are in the data sheet, just
> put them directly into the dts file, as we do for interrupt numbers,
> gpio numbers, register offsets etc.
>
> If you have made them up to define an interface between the driver
> and DT because there is no usable hardare ID, I'd suggest just using
> a single file across all SoCs that have this driver, and have
> a unified name space.
Also, it's a bit unclear how the reset controller phandle is used
referenced and used by the consumer device.. Maybe setting that up
first in a Linux generic way is a good point starting point.
Maybe something like this along the same way as clocks are set up
(completely untested):
&reset1 {
iva_reset: reset1 {
reg = /bits/ 8 <0>;
};
gfx_reset: reset1 {
reg = /bits/ 8 <1>;
};
...
};
&iva {
compatible = "ti,ivahd";
resets = <&reset1 1>;
...
};
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
Otherwise we can get often errors like the following and the
display won't come on:
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled
There are some earlier references to this issue:
http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html
It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.
Signed-off-by: Tony Lindgren
---
drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats
__initconst = {
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
};
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max= 32,
- .dss_fck_multiplier = 1,
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
.parent_clk_name= "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
};
--
1.8.1.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] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.
Signed-off-by: Tony Lindgren
---
.../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++
arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +
arch/arm/boot/dts/omap3-evm-common.dtsi| 47 +
arch/arm/boot/dts/omap3-ldp.dts| 31 ++--
4 files changed, 205 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ startup-delay-us = <7>;
+ regulator-always-on;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+ panel-timing {
+ clock-frequency = <540>;
+ hback-porch = <39>;
+ hactive = <240>;
+ hfront-porch = <3>;
+ hsync-len = <3>;
+ vback-porch = <7>;
+ vactive = <320>;
+ vfront-porch = <2>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <100>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts
b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &dss_dpi_pins1
+ &dss_dpi_pins2
+ >;
+};
+
&omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /*
dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /*
dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /*
dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /*
dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /*
dss_data6.
[PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
Using gpiod will make it easier to add device tree support
for this panel in the following patches.
Note that all the GPIOs for this panel are optional, any
of the the GPIOs could be configured with external pulls
instead of GPIOs, so let's not error out if GPIOs are not
found to make the panel more generic.
Signed-off-by: Tony Lindgren
---
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 92 +-
1 file changed, 38 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index b2f710b..de8473a 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -26,11 +26,11 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- int resb_gpio;
- int ini_gpio;
- int mo_gpio;
- int lr_gpio;
- int ud_gpio;
+ struct gpio_desc *resb_gpio;/* low = reset active min 20 us */
+ struct gpio_desc *ini_gpio; /* high = power on */
+ struct gpio_desc *mo_gpio; /* low = 480x640, high = 240x320 */
+ struct gpio_desc *lr_gpio; /* high = conventional horizontal
scanning */
+ struct gpio_desc *ud_gpio; /* high = conventional vertical
scanning */
};
static const struct omap_video_timings sharp_ls_timings = {
@@ -105,11 +105,11 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
- if (gpio_is_valid(ddata->resb_gpio))
- gpio_set_value_cansleep(ddata->resb_gpio, 1);
+ if (!IS_ERR(ddata->resb_gpio))
+ gpiod_set_value_cansleep(ddata->resb_gpio, 1);
- if (gpio_is_valid(ddata->ini_gpio))
- gpio_set_value_cansleep(ddata->ini_gpio, 1);
+ if (!IS_ERR(ddata->ini_gpio))
+ gpiod_set_value_cansleep(ddata->ini_gpio, 1);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -124,11 +124,11 @@ static void sharp_ls_disable(struct omap_dss_device
*dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->ini_gpio))
- gpio_set_value_cansleep(ddata->ini_gpio, 0);
+ if (!IS_ERR(ddata->ini_gpio))
+ gpiod_set_value_cansleep(ddata->ini_gpio, 0);
- if (gpio_is_valid(ddata->resb_gpio))
- gpio_set_value_cansleep(ddata->resb_gpio, 0);
+ if (!IS_ERR(ddata->resb_gpio))
+ gpiod_set_value_cansleep(ddata->resb_gpio, 0);
/* wait at least 5 vsyncs after disabling the LCD */
@@ -182,6 +182,21 @@ static struct omap_dss_driver sharp_ls_ops = {
.get_resolution = omapdss_default_get_resolution,
};
+static struct gpio_desc *
+sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
+ char *desc)
+{
+ int r;
+
+ r = devm_gpio_request_one(dev, gpio, flags, desc);
+ if (r) {
+ dev_err(dev, "no %s gpio\n", desc);
+ return ERR_PTR(r);
+ }
+
+ return gpio_to_desc(gpio);
+}
+
static int sharp_ls_probe_pdata(struct platform_device *pdev)
{
const struct panel_sharp_ls037v7dw01_platform_data *pdata;
@@ -204,11 +219,16 @@ static int sharp_ls_probe_pdata(struct platform_device
*pdev)
dssdev = &ddata->dssdev;
dssdev->name = pdata->name;
- ddata->resb_gpio = pdata->resb_gpio;
- ddata->ini_gpio = pdata->ini_gpio;
- ddata->mo_gpio = pdata->mo_gpio;
- ddata->lr_gpio = pdata->lr_gpio;
- ddata->ud_gpio = pdata->ud_gpio;
+ ddata->mo_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->mo_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd MO");
+ ddata->lr_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->lr_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd LR");
+ ddata->ud_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ud_gpio,
+ GPIOF_OUT_INIT_HIGH, "lcd UD");
+ ddata->resb_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->resb_gpio,
+GPIOF_OUT_INIT_LOW, "lcd RESB");
+ ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
+ GPIOF_OUT_INIT_LOW, "lcd INI");
return 0;
}
@@ -233,41 +253,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (gpio_is_valid(ddata->mo_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->mo_gpio,
- GPIOF_OUT_INIT_LOW, "lcd MO");
- if (r)
- goto err_gpio;
- }
-
- if (gpio_is_valid(ddata->lr_gpio)) {
- r = devm_gpio_request_one(&pdev->dev, ddata->lr_gpio,
- GPIO
[PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
We can pass the GPIO configuration for ls037v7dw01 in a standard
gpios property.
Signed-off-by: Tony Lindgren
---
.../bindings/panel/sharp,ls037v7dw01.txt | 53 ++
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 84 --
2 files changed, 133 insertions(+), 4 deletions(-)
create mode 100644
Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
new file mode 100644
index 000..7f6f5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
@@ -0,0 +1,53 @@
+SHARP LS037V7DW01 TFT-LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls037v7dw01"
+
+Optional properties:
+- reset-gpios: a GPIO spec for the optional reset pin
+- enable-gpios: a GPIO array for the optional configuration GPIOs
+ ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example when connected to a omap2+ based device:
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ power-supply = <&lcd_3v3>;
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd
RESB */
+ enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd
MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd
LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd
UD */
+ &gpio5 24 GPIO_ACTIVE_HIGH>;/* gpio152, lcd
INI */
+
+ panel-timing {
+ clock-frequency = <1920>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index de8473a..3a04fb0 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,19 @@
#include
#include
#include
+#include
+#include
#include
#include
-
+#include
+#include
#include
#include
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
+ struct regulator *vcc;
int data_lines;
@@ -95,7 +99,8 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
r = in->ops.dpi->enable(in);
@@ -230,6 +235,67 @@ static int sharp_ls_probe_pdata(struct platform_device
*pdev)
ddata->ini_gpio = sharp_ls_get_gpio(&pdev->dev, pdata->ini_gpio,
GPIOF_OUT_INIT_LOW, "lcd INI");
+ ddata->videomode = sharp_ls_timings;
+
+ return 0;
+}
+
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get_index(dev, desc, index);
+ if (!IS_ERR(gpio))
+ gpiod_direction_output(gpio, val);
+
+ return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ struct display_timing timing;
+ struct videomode vm;
+ int r;
+
+ ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+ if (IS_ERR(ddata->vcc)) {
+ dev_err(&pdev->dev, "failed to get regulator\n");
+ return PTR_ERR(ddata->vcc);
+ }
+
+ r = regulator_enable(ddata->vcc);
+ i
[PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
Hi all, Here are few patches to add devicetree support for panel ls037v7dw01 that's found on many omap3 boards. They seem to be often mis-configured as various panel dpi entries, but really should be move to use panel ls037v7dw01 instead. This panel is found at least on the omap3 sdp, ldp, omap3 evm and few other development boards. Regards, Tony Tony Lindgren (4): OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630 OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod OMAPDSS: panel-sharp-ls037v7dw01: add device tree support ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp .../bindings/panel/sharp,ls037v7dw01.txt | 53 +++ .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++ arch/arm/boot/dts/omap3-evm-37xx.dts | 50 ++ arch/arm/boot/dts/omap3-evm-common.dtsi| 47 ++ arch/arm/boot/dts/omap3-ldp.dts| 31 +++- .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 176 ++--- drivers/video/fbdev/omap2/dss/dss.c| 5 +- 7 files changed, 379 insertions(+), 65 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi -- 1.8.1.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: [PATCHv2 3/9] ASoC: omap: rx51: Use devm_snd_soc_register_card
On Mon, Apr 28, 2014 at 04:07:21PM +0200, Sebastian Reichel wrote: > This patch converts the rx51 ASoC module to use > devm_snd_soc_register_card. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCHv2 2/9] ASoC: omap: rx51: Add module alias
On Mon, Apr 28, 2014 at 04:07:20PM +0200, Sebastian Reichel wrote: > Add module alias to support driver autoloading. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCHv2 1/9] ASoC: omap: rx51: Use static const char * const arrays
On Mon, Apr 28, 2014 at 04:07:19PM +0200, Sebastian Reichel wrote: > Mark the array and the string const by using "static const char * const > foo[]" instead of "static const char* foo[]". Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/5] ASoC: Add HA (HEAD acoustics) DSP codec driver template
On Mon, Apr 28, 2014 at 02:17:53PM +0200, Stefan Roese wrote:
> +static int ha_dsp_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct snd_soc_codec *codec = rtd->codec;
> +
> + dev_dbg(codec->dev, "Sample format 0x%X\n", params_format(params));
> + dev_dbg(codec->dev, "Channels %d\n", params_channels(params));
> + dev_dbg(codec->dev, "Rate %d\n", params_rate(params));
> +
> + return 0;
> +}
This doesn't do anything, you should either implement active code here
or remove it (I note that a range of sample rates are supported and the
CODEC can be clock master so I'd expect to see code here).
> + /* codec role */
> + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
> + case SND_SOC_DAIFMT_CBM_CFM:
> + dev_dbg(codec->dev, "Codec is master\n");
> + break;
> + case SND_SOC_DAIFMT_CBS_CFS:
> + dev_dbg(codec->dev, "Codec is slave\n");
> + break;
> + default:
> + return -EINVAL;
> + }
This isn't doing anything with what it parsed, how does that work?
> +/*
> + * This name/ID is neded to match the DT node for the codec
> + */
> +static const struct i2c_device_id ha_dsp_i2c_id[] = {
> + { "ha-dsp-audio", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, ha_dsp_i2c_id);
This doesn't have any actual part numbers?
signature.asc
Description: Digital signature
Re: [RFC 01/11] drivers: reset: TI: SoC reset controller support.
On Tuesday 29 April 2014 15:19:40 Dan Murphy wrote:
> +#ifndef _RESET_TI_H_
> +#define _RESET_TI_H_
> +
> +#ifdef CONFIG_RESET_TI
> +void ti_dt_reset_init(void);
> +#else
> +static inline void ti_dt_reset_init(void){ return; };
> +#endif
Why can't this be a regular platform device driver that gets
initialized through an initcall rather than get called from
platform code?
Arnd
--
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 08/11] ARM: dts: am33xx: Add prcm_resets node
On Tuesday 29 April 2014 15:19:47 Dan Murphy wrote: > + * AM33xx reset index for PRCM Module > + * > + * Copyright 2014 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. > + */ > + > +#ifndef _DT_BINDINGS_RESET_TI_AM33XX_H > +#define _DT_BINDINGS_RESET_TI_AM33XX_H > + > +#define RESET_DEVICE_RESET 0 > +#define RESET_GFX_RESET1 > +#define RESET_PER_RESET2 > + > +#endif Interfaces like this should only be used if you can't use hardware numbers, in general. If these numbers are in the data sheet, just put them directly into the dts file, as we do for interrupt numbers, gpio numbers, register offsets etc. If you have made them up to define an interface between the driver and DT because there is no usable hardare ID, I'd suggest just using a single file across all SoCs that have this driver, and have a unified name space. Arnd -- 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
[RFC 09/11] ARM: dts: am4372: Add prcm_resets node
Add the prcm_resets node to the prcm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/am4372.dtsi|6 ++
include/dt-bindings/reset/ti,am437x-resets.h | 19 +++
2 files changed, 25 insertions(+)
create mode 100644 include/dt-bindings/reset/ti,am437x-resets.h
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a..f8bd4ca 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -10,6 +10,7 @@
#include
#include
+#include
#include "skeleton.dtsi"
@@ -84,6 +85,11 @@
prcm_clockdomains: clockdomains {
};
+
+ prcm_resets: resets {
+ compatible = "ti,am4372-resets";
+ #reset-cells = <1>;
+ };
};
scrm: scrm@44e1 {
diff --git a/include/dt-bindings/reset/ti,am437x-resets.h
b/include/dt-bindings/reset/ti,am437x-resets.h
new file mode 100644
index 000..cf3e329
--- /dev/null
+++ b/include/dt-bindings/reset/ti,am437x-resets.h
@@ -0,0 +1,19 @@
+/*
+ * AM437x reset index for PRCM Module
+ *
+ * Copyright 2014 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_AM437X_H
+#define _DT_BINDINGS_RESET_TI_AM437X_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_ICSS_RESET 1
+#define RESET_GFX_RESET2
+#define RESET_PER_RESET3
+
+#endif
--
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
[RFC 03/11] drivers: reset: omap5: Add reset data for omap5
Add the reset register data for the omap5 SoC.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-data.h |2 ++
drivers/reset/ti/reset-ti-omap5.c | 61 +
drivers/reset/ti/reset-ti.c |3 ++
4 files changed, 67 insertions(+)
create mode 100644 drivers/reset/ti/reset-ti-omap5.c
diff --git a/drivers/reset/ti/Makefile b/drivers/reset/ti/Makefile
index 622eb3b..4d2d06c 100644
--- a/drivers/reset/ti/Makefile
+++ b/drivers/reset/ti/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_RESET_TI) += reset-ti.o
obj-$(CONFIG_SOC_DRA7XX) += reset-ti-dra7xx.o
+obj-$(CONFIG_SOC_OMAP5) += reset-ti-omap5.o
diff --git a/drivers/reset/ti/reset-ti-data.h b/drivers/reset/ti/reset-ti-data.h
index 5812ed5..d3c6d42 100644
--- a/drivers/reset/ti/reset-ti-data.h
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -56,4 +56,6 @@ struct ti_reset_data {
};
extern struct ti_reset_data dra7_reset_data;
+extern struct ti_reset_data omap5_reset_data;
+
#endif
diff --git a/drivers/reset/ti/reset-ti-omap5.c
b/drivers/reset/ti/reset-ti-omap5.c
new file mode 100644
index 000..3e7529c
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-omap5.c
@@ -0,0 +1,61 @@
+/*
+ * OMAP5 reset data for PRCM Module
+ *
+ * Copyright 2014 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 "reset-ti-data.h"
+
+static struct ti_reset_reg_data omap5_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0x1c00,
+ .rstctrl_bit = 0x0,
+ .rstst_offs = 0x1c04,
+ .rstst_bit = 0x0,
+ },
+ {
+ .rstctrl_offs = 0x410,
+ .rstctrl_bit = 0x0,
+ .rstst_offs = 0x414,
+ .rstst_bit = 0x0,
+ }, /* DSP_RESET */
+ {
+ .rstctrl_offs = 0x410,
+ .rstctrl_bit = 0x1,
+ .rstst_offs = 0x414,
+ .rstst_bit = 0x1,
+ }, /* DSP_MMU_CACHE */
+ {
+ .rstctrl_offs = 0x910,
+ .rstctrl_bit = 0x0,
+ .rstst_offs = 0x914,
+ .rstst_bit = 0x0,
+ }, /* IPU_CPU0 */
+ {
+ .rstctrl_offs = 0x910,
+ .rstctrl_bit = 0x1,
+ .rstst_offs = 0x914,
+ .rstst_bit = 0x1,
+ }, /* IPU_CPU1 */
+ {
+ .rstctrl_offs = 0x910,
+ .rstctrl_bit = 0x2,
+ .rstst_offs = 0x914,
+ .rstst_bit = 0x2,
+ }, /* IPU_MMU_CACHE */
+ {
+ .rstctrl_offs = 0x1210,
+ .rstctrl_bit = 0,
+ .rstst_offs = 0x1214,
+ .rstst_bit = 0,
+ },
+};
+
+struct ti_reset_data omap5_reset_data = {
+ .reg_data = omap5_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(omap5_reset_reg_data),
+};
diff --git a/drivers/reset/ti/reset-ti.c b/drivers/reset/ti/reset-ti.c
index 486b77c..7310827 100644
--- a/drivers/reset/ti/reset-ti.c
+++ b/drivers/reset/ti/reset-ti.c
@@ -135,6 +135,9 @@ static const struct of_device_id ti_reset_of_match[] = {
#ifdef CONFIG_SOC_DRA7XX
{ .compatible = "ti,dra7-resets", .data = &dra7_reset_data,},
#endif
+#ifdef CONFIG_SOC_OMAP5
+ { .compatible = "ti,omap5-resets", .data = &omap5_reset_data,},
+#endif
{},
};
--
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
[RFC] TI Reset Driver adapted to the reset core
This is a RFC on the TI reset adoption to the Reset framework. The patchset was derived from work from Rajendra Nayak and Afzal Mohammed who have had similar code offerings. One of the major differences here is the SoC data has been broken out so that the data and code are independent. There is currently no OMAP4 or prior support added to this patch series. Once the RFC is complete and the code infrastructure looks to be acceptable I will add these data sets into the patchset. Dan -- 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
[RFC 11/11] ARM: dts: omap5: Add prm_resets node
Add the prm_resets node to the prm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap5.dtsi|6 ++
include/dt-bindings/reset/ti,omap5-resets.h | 22 ++
2 files changed, 28 insertions(+)
create mode 100644 include/dt-bindings/reset/ti,omap5-resets.h
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f8c9855..82eebe7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "skeleton.dtsi"
@@ -134,6 +135,11 @@
prm_clockdomains: clockdomains {
};
+
+ prm_resets: resets {
+ compatible = "ti,omap5-resets";
+ #reset-cells = <1>;
+ };
};
cm_core_aon: cm_core_aon@4a004000 {
diff --git a/include/dt-bindings/reset/ti,omap5-resets.h
b/include/dt-bindings/reset/ti,omap5-resets.h
new file mode 100644
index 000..33bb295
--- /dev/null
+++ b/include/dt-bindings/reset/ti,omap5-resets.h
@@ -0,0 +1,22 @@
+/*
+ * OMAP5 reset index for PRCM Module
+ *
+ * Copyright 2014 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_OMAP5_H
+#define _DT_BINDINGS_RESET_TI_OMAP5_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_DSP_RESET1
+#define RESET_DSP_MMU_CACHE_RESET 2
+#define RESET_IPU_CPU0_RESET 3
+#define RESET_IPU_CPU1_RESET 4
+#define RESET_IPU_MMU_CACHE_RESET 5
+#define RESET_IVA_RESET6
+
+#endif
--
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
[RFC 05/11] drivers: reset: am43xx: Add reset data for am43xx
Add the reset register data for the am43xx SoC.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-am43xx.c | 43
drivers/reset/ti/reset-ti-data.h |1 +
3 files changed, 45 insertions(+)
create mode 100644 drivers/reset/ti/reset-ti-am43xx.c
diff --git a/drivers/reset/ti/Makefile b/drivers/reset/ti/Makefile
index f0dbd01..3d362c2 100644
--- a/drivers/reset/ti/Makefile
+++ b/drivers/reset/ti/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_RESET_TI) += reset-ti.o
obj-$(CONFIG_SOC_DRA7XX) += reset-ti-dra7xx.o
obj-$(CONFIG_SOC_OMAP5) += reset-ti-omap5.o
obj-$(CONFIG_SOC_AM33XX) += reset-ti-am33xx.o
+obj-$(CONFIG_SOC_AM43XX) += reset-ti-am43xx.o
diff --git a/drivers/reset/ti/reset-ti-am43xx.c
b/drivers/reset/ti/reset-ti-am43xx.c
new file mode 100644
index 000..cfb283b
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-am43xx.c
@@ -0,0 +1,43 @@
+/*
+ * am43xx reset data for PRCM Module
+ *
+ * Copyright 2014 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 "reset-ti-data.h"
+
+static struct ti_reset_reg_data am43x_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0x4000,
+ .rstctrl_bit = 0,
+ .rstst_offs = 0x4004,
+ .rstst_bit = 0,
+ },
+ {
+ .rstctrl_offs = 0x810,
+ .rstctrl_bit = 1,
+ .rstst_offs = 0x814,
+ .rstst_bit = 0,
+ },
+ {
+ .rstctrl_offs = 0x410,
+ .rstst_offs = 0x414,
+ .rstctrl_bit= 0,
+ .rstst_bit = 0,
+ },
+ {
+ .rstctrl_offs = 0x2010,
+ .rstst_offs = 0x2014,
+ .rstctrl_bit= 3,
+ .rstst_bit = 5,
+ },
+};
+
+struct ti_reset_data am43x_reset_data = {
+ .reg_data = am43x_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(am43x_reset_reg_data),
+};
diff --git a/drivers/reset/ti/reset-ti-data.h b/drivers/reset/ti/reset-ti-data.h
index 48a1476..f56f1a5 100644
--- a/drivers/reset/ti/reset-ti-data.h
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -58,5 +58,6 @@ struct ti_reset_data {
extern struct ti_reset_data dra7_reset_data;
extern struct ti_reset_data omap5_reset_data;
extern struct ti_reset_data am335x_reset_data;
+extern struct ti_reset_data am43x_reset_data;
#endif
--
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
[RFC 02/11] drivers: reset: dra7: Add reset data for dra7xx
Add the reset register data for the dra7xx SoC.
Include the dt-bindings header to properly index
the right reset node.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-data.h |1 +
drivers/reset/ti/reset-ti-dra7xx.c | 61
drivers/reset/ti/reset-ti.c|3 ++
4 files changed, 66 insertions(+)
create mode 100644 drivers/reset/ti/reset-ti-dra7xx.c
diff --git a/drivers/reset/ti/Makefile b/drivers/reset/ti/Makefile
index 55ab3f5..622eb3b 100644
--- a/drivers/reset/ti/Makefile
+++ b/drivers/reset/ti/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_RESET_TI) += reset-ti.o
+obj-$(CONFIG_SOC_DRA7XX) += reset-ti-dra7xx.o
diff --git a/drivers/reset/ti/reset-ti-data.h b/drivers/reset/ti/reset-ti-data.h
index 6afdf37..5812ed5 100644
--- a/drivers/reset/ti/reset-ti-data.h
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -55,4 +55,5 @@ struct ti_reset_data {
u8 nr_resets;
};
+extern struct ti_reset_data dra7_reset_data;
#endif
diff --git a/drivers/reset/ti/reset-ti-dra7xx.c
b/drivers/reset/ti/reset-ti-dra7xx.c
new file mode 100644
index 000..764f83e
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-dra7xx.c
@@ -0,0 +1,61 @@
+/*
+ * dra7xx reset data for PRCM Module
+ *
+ * Copyright 2014 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 "reset-ti-data.h"
+
+static struct ti_reset_reg_data dra7_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0x1D00,
+ .rstctrl_bit = 0x0,
+ .rstst_offs = 0x1D04,
+ .rstst_bit = 0x0,
+ },
+ {
+ .rstctrl_offs = 0x410,
+ .rstctrl_bit = 0x0,
+ .rstst_offs = 0x414,
+ .rstst_bit = 0x0,
+ },
+ {
+ .rstctrl_offs = 0x510,
+ .rstctrl_bit = 0x0,
+ .rstst_offs = 0x514,
+ .rstst_bit = 0x0,
+ }, /* IPU_CPU0 */
+ {
+ .rstctrl_offs = 0x510,
+ .rstctrl_bit = 0x1,
+ .rstst_offs = 0x514,
+ .rstst_bit = 0x1,
+ }, /* IPU_CPU1 */
+ {
+ .rstctrl_offs = 0x510,
+ .rstctrl_bit = 0x2,
+ .rstst_offs = 0x514,
+ .rstst_bit = 0x2,
+ }, /* IPU_MMU_CACHE */
+ {
+ .rstctrl_offs = 0xf10,
+ .rstctrl_bit = 0,
+ .rstst_offs = 0xf14,
+ .rstst_bit = 0,
+ },
+ {
+ .rstctrl_offs = 0x1310,
+ .rstctrl_bit = 0,
+ .rstst_offs = 0x1314,
+ .rstst_bit = 0,
+ },
+};
+
+struct ti_reset_data dra7_reset_data = {
+ .reg_data = dra7_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(dra7_reset_reg_data),
+};
diff --git a/drivers/reset/ti/reset-ti.c b/drivers/reset/ti/reset-ti.c
index 1d38069..486b77c 100644
--- a/drivers/reset/ti/reset-ti.c
+++ b/drivers/reset/ti/reset-ti.c
@@ -132,6 +132,9 @@ static struct reset_control_ops ti_reset_ops = {
};
static const struct of_device_id ti_reset_of_match[] = {
+#ifdef CONFIG_SOC_DRA7XX
+ { .compatible = "ti,dra7-resets", .data = &dra7_reset_data,},
+#endif
{},
};
--
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
[RFC 08/11] ARM: dts: am33xx: Add prcm_resets node
Add the prcm_resets node to the prcm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/am33xx.dtsi|6 ++
include/dt-bindings/reset/ti,am33xx-resets.h | 18 ++
2 files changed, 24 insertions(+)
create mode 100644 include/dt-bindings/reset/ti,am33xx-resets.h
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 07f283c..df9d9c6 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -10,6 +10,7 @@
#include
#include
+#include
#include "skeleton.dtsi"
@@ -117,6 +118,11 @@
prcm_clockdomains: clockdomains {
};
+
+ prcm_resets: resets {
+ compatible = "ti,am335x-resets";
+ #reset-cells = <1>;
+ };
};
scrm: scrm@44e1 {
diff --git a/include/dt-bindings/reset/ti,am33xx-resets.h
b/include/dt-bindings/reset/ti,am33xx-resets.h
new file mode 100644
index 000..dfe7954
--- /dev/null
+++ b/include/dt-bindings/reset/ti,am33xx-resets.h
@@ -0,0 +1,18 @@
+/*
+ * AM33xx reset index for PRCM Module
+ *
+ * Copyright 2014 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_AM33XX_H
+#define _DT_BINDINGS_RESET_TI_AM33XX_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_GFX_RESET1
+#define RESET_PER_RESET2
+
+#endif
--
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
[RFC 04/11] drivers: reset: am335: Add reset data for am335
Add the reset register data for the am335 SoC.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-am33xx.c | 37
drivers/reset/ti/reset-ti-data.h |1 +
drivers/reset/ti/reset-ti.c|3 +++
4 files changed, 42 insertions(+)
create mode 100644 drivers/reset/ti/reset-ti-am33xx.c
diff --git a/drivers/reset/ti/Makefile b/drivers/reset/ti/Makefile
index 4d2d06c..f0dbd01 100644
--- a/drivers/reset/ti/Makefile
+++ b/drivers/reset/ti/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_RESET_TI) += reset-ti.o
obj-$(CONFIG_SOC_DRA7XX) += reset-ti-dra7xx.o
obj-$(CONFIG_SOC_OMAP5) += reset-ti-omap5.o
+obj-$(CONFIG_SOC_AM33XX) += reset-ti-am33xx.o
diff --git a/drivers/reset/ti/reset-ti-am33xx.c
b/drivers/reset/ti/reset-ti-am33xx.c
new file mode 100644
index 000..d28f41b
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-am33xx.c
@@ -0,0 +1,37 @@
+/*
+ * am33xx reset data for PRCM Module
+ *
+ * Copyright 2014 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 "reset-ti-data.h"
+
+static struct ti_reset_reg_data am335x_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0xf00,
+ .rstctrl_bit = 0,
+ .rstst_offs = 0xf08,
+ .rstst_bit = 0,
+ },
+ {
+ .rstctrl_offs = 0x1104,
+ .rstctrl_bit = 0,
+ .rstst_offs = 0x1114,
+ .rstst_bit = 0,
+ },
+ {
+ .rstctrl_offs = 0x0D00,
+ .rstctrl_bit = 3,
+ .rstst_offs = 0x0D0C,
+ .rstst_bit = 5,
+ },
+};
+
+struct ti_reset_data am335x_reset_data = {
+ .reg_data = am335x_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(am335x_reset_reg_data),
+};
diff --git a/drivers/reset/ti/reset-ti-data.h b/drivers/reset/ti/reset-ti-data.h
index d3c6d42..48a1476 100644
--- a/drivers/reset/ti/reset-ti-data.h
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -57,5 +57,6 @@ struct ti_reset_data {
extern struct ti_reset_data dra7_reset_data;
extern struct ti_reset_data omap5_reset_data;
+extern struct ti_reset_data am335x_reset_data;
#endif
diff --git a/drivers/reset/ti/reset-ti.c b/drivers/reset/ti/reset-ti.c
index 7310827..146353f 100644
--- a/drivers/reset/ti/reset-ti.c
+++ b/drivers/reset/ti/reset-ti.c
@@ -138,6 +138,9 @@ static const struct of_device_id ti_reset_of_match[] = {
#ifdef CONFIG_SOC_OMAP5
{ .compatible = "ti,omap5-resets", .data = &omap5_reset_data,},
#endif
+#ifdef CONFIG_SOC_AM33XX
+ { .compatible = "ti,am335x-resets", .data = &am335x_reset_data,},
+#endif
{},
};
--
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
[RFC 01/11] drivers: reset: TI: SoC reset controller support.
The TI SoC reset controller support utilizes the
reset controller framework to give device drivers or
function drivers a common set of APIs to call to reset
a module.
The reset-ti is a common interface to the reset framework.
The register data is retrieved during initialization
of the reset driver through the reset-ti-data
file. The array of data is associated with the compatible from the
respective DT entry.
Once the data is available then this is derefenced within the common
interface.
The device driver has the ability to assert, deassert or perform a
complete reset.
This code was derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
Signed-off-by: Dan Murphy
---
drivers/reset/Kconfig|1 +
drivers/reset/Makefile |1 +
drivers/reset/ti/Kconfig |8 ++
drivers/reset/ti/Makefile|1 +
drivers/reset/ti/reset-ti-data.h | 58
drivers/reset/ti/reset-ti.c | 195 ++
include/linux/reset_ti.h | 25 +
7 files changed, 289 insertions(+)
create mode 100644 drivers/reset/ti/Kconfig
create mode 100644 drivers/reset/ti/Makefile
create mode 100644 drivers/reset/ti/reset-ti-data.h
create mode 100644 drivers/reset/ti/reset-ti.c
create mode 100644 include/linux/reset_ti.h
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..a58d789 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
source "drivers/reset/sti/Kconfig"
+source "drivers/reset/ti/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4f60caf..1c8c444 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_RESET_TI) += ti/
diff --git a/drivers/reset/ti/Kconfig b/drivers/reset/ti/Kconfig
new file mode 100644
index 000..dcdce90
--- /dev/null
+++ b/drivers/reset/ti/Kconfig
@@ -0,0 +1,8 @@
+config RESET_TI
+ depends on RESET_CONTROLLER
+ bool "TI reset controller"
+ help
+ Reset controller support for TI SoC's
+
+ Reset controller found in TI's AM series of SoC's like
+ AM335x and AM43x and OMAP SoC's like OMAP5 and DRA7
diff --git a/drivers/reset/ti/Makefile b/drivers/reset/ti/Makefile
new file mode 100644
index 000..55ab3f5
--- /dev/null
+++ b/drivers/reset/ti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RESET_TI) += reset-ti.o
diff --git a/drivers/reset/ti/reset-ti-data.h b/drivers/reset/ti/reset-ti-data.h
new file mode 100644
index 000..6afdf37
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -0,0 +1,58 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * 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.
+ */
+
+#ifndef _RESET_TI_DATA_H_
+#define _RESET_TI_DATA_H_
+
+#include
+#include
+#include
+
+/**
+ * struct ti_reset_reg_data - Structure of the reset register information
+ * for a particular SoC.
+ * @rstctrl_offs: This is the reset control offset value from
+ * from the parent reset node.
+ * @rstst_offs: This is the reset status offset value from
+ * from the parent reset node.
+ * @rstctrl_bit: This is the reset control bit for the module.
+ * @rstst_bit: This is the reset status bit for the module.
+ *
+ * This structure describes the reset register control and status offsets.
+ * The bits are also defined for the same.
+ */
+struct ti_reset_reg_data {
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u8 rstctrl_bit;
+ u8 rstst_bit;
+};
+
+/**
+ * struct ti_reset_data - Structure that contains the reset register data
+ * as well as the total number of resets for a particular SoC.
+ * @reg_data: Pointer to the register data structure.
+ * @nr_resets: Total number of resets for the SoC in the reset array.
+ *
+ * This structure contains a pointer to the register data and the modules
+ * register base. The number of resets and reset controller device data is
+ * stored within this structure.
+ *
+ */
+struct ti_reset_data {
+ struct ti_reset_reg_data *reg_data;
+ struct reset_controller_dev rcdev;
+ void __iomem *reg_base;
+ u8 nr_resets;
+};
+
+#endif
diff --git a/drivers/reset/ti/reset-ti.c b/drivers/reset/ti/reset-ti.c
new file mode 100644
index 000..1d38069
--- /dev/null
+++ b/drivers/reset/ti/reset-ti.c
@@ -0,0 +1,195 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can red
[RFC 06/11] ARM: OMAP: Add reset init to prcm file
Call the reset init API to initialize the reset framework and data for the related SoC. Signed-off-by: Dan Murphy --- arch/arm/mach-omap2/prm_common.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c index b4c4ab9..7e95f8e 100644 --- a/arch/arm/mach-omap2/prm_common.c +++ b/arch/arm/mach-omap2/prm_common.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "soc.h" #include "prm2xxx_3xxx.h" @@ -523,10 +524,13 @@ int __init of_prcm_init(void) mem = of_iomap(np, 0); clk_memmaps[memmap_index] = mem; ti_dt_clk_init_provider(np, memmap_index); + memmap_index++; } ti_dt_clockdomains_setup(); + ti_dt_reset_init(); + return 0; } -- 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
[RFC 07/11] ARM: TI: Describe the ti reset DT entries
Describe the TI reset DT entries for TI SoC's.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/reset/ti,reset.txt | 34
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,reset.txt
diff --git a/Documentation/devicetree/bindings/reset/ti,reset.txt
b/Documentation/devicetree/bindings/reset/ti,reset.txt
new file mode 100644
index 000..19f5603
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,reset.txt
@@ -0,0 +1,34 @@
+Texas Instruments Reset Controller
+==
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Specifying the reset entries for the IP module
+==
+Parent module:
+This is the module node that contains the reset registers and bits.
+
+example:
+ prcm_resets: resets {
+ compatible = "ti,dra7-resets";
+ #reset-cells = <1>;
+ };
+
+Required Properties:
+compatible - Should be "ti--resets
+
+DRA7xx:
+Compatible - ti,dra7-resets
+Reset indices - include/dt-bindings/reset/ti,dra7-resets.h
+
+OMAP5:
+Compatible - ti,omap5-resets
+Reset indices - include/dt-bindings/reset/ti,omap5-resets.h
+
+AM33xx:
+Compatible - ti-am335x-resets
+Reset indices - include/dt-bindings/reset/ti,am33xx-resets.h
+
+AM43xx:
+Compatible - ti,am4372-resets
+Reset indices - include/dt-bindings/reset/ti,am437x-resets.h
--
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
[RFC 10/11] ARM: dts: dra7: Add prm_resets node
Add the prcm_resets node to the prm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/dra7.dtsi|6 ++
include/dt-bindings/reset/ti,dra7-resets.h | 22 ++
2 files changed, 28 insertions(+)
create mode 100644 include/dt-bindings/reset/ti,dra7-resets.h
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..3507730 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -9,6 +9,7 @@
#include
#include
+#include
#include "skeleton.dtsi"
@@ -120,6 +121,11 @@
prm_clockdomains: clockdomains {
};
+
+ prm_resets: resets {
+ compatible = "ti,dra7-resets";
+ #reset-cells = <1>;
+ };
};
cm_core_aon: cm_core_aon@4a005000 {
diff --git a/include/dt-bindings/reset/ti,dra7-resets.h
b/include/dt-bindings/reset/ti,dra7-resets.h
new file mode 100644
index 000..89be87b
--- /dev/null
+++ b/include/dt-bindings/reset/ti,dra7-resets.h
@@ -0,0 +1,22 @@
+/*
+ * DRA7xx reset index for PRCM Module
+ *
+ * Copyright 2014 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_DRA7_H
+#define _DT_BINDINGS_RESET_TI_DRA7_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_DSP1_RESET 1
+#define RESET_IPU_CPU0_RESET 2
+#define RESET_IPU_CPU1_RESET 3
+#define RESET_IPU_MMU_CACHE_RESET 4
+#define RESET_IVA_RESET5
+#define RESET_PCIE_RESET 6
+
+#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ASoC: Add support for machine specific trigger callback
On Mon, Apr 28, 2014 at 02:17:52PM +0200, Stefan Roese wrote: > From: Jarkko Nikula > > Machine specific trigger callback allows to do final stream start/stop > related operations in a machine driver after setting up the codec, DMA and > DAI. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 3/5] ASoC: omap: Add HA (HEAD acoustics) DSP add-on card audio driver for TAO3530
On Mon, Apr 28, 2014 at 02:17:54PM +0200, Stefan Roese wrote:
> + switch (params_channels(params)) {
> + case 2:
> + case 4:
> + case 8:
> + case 16:
> + fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_IB_NF;
> + break;
> + default:
> + return -EINVAL;
> + }
Why is this "conditional" on the number of channels (though the same
value is always chosen)?
> + /*
> + * Calculate McBSP SRG divisor in McBSP master mode
> + */
> + div = 9600 / params_rate(params) / params_channels(params);
> + switch (params_format(params)) {
> + case SNDRV_PCM_FORMAT_S16_LE:
> + div /= 16;
> + break;
> + case SNDRV_PCM_FORMAT_S24_LE:
> + case SNDRV_PCM_FORMAT_S32_LE:
> + div /= 32;
> + break;
> + };
params_width().
> + ret = snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, div);
> + if (ret < 0) {
> + pr_err("can't set SRG clock divider\n");
> + return ret;
> + }
Why not put this code into the DAI driver for the SoC - what's board
specific about the calcuation? I'd expect this to be handlable by
set_sysclk().
> + if (!node) {
> + dev_err(&pdev->dev, "No DT node provided\n");
> + return -ENODEV;
> + }
You've got something with a DT binding here but no binding document,
documentation is mandatory for new DT bindings.
> + priv->slave = of_property_read_bool(node, "ha_dsp_codec_slave");
> + if (priv->slave)
> + dev_info(&pdev->dev, "Using slave mode for testing!\n");
This seems like something that shouldn't be in production code, or
perhaps a build time option if the testing is valuable?
> + if (snd_soc_of_parse_card_name(card, "ti,model")) {
> + dev_err(&pdev->dev, "Card name is not provided\n");
> + ret = -ENODEV;
> + goto err;
> + }
Why not have a default?
> + ret = snd_soc_register_card(card);
> + if (ret) {
> + dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n",
> + ret);
> + goto err;
> + }
devm_snd_soc_register_card().
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On Tue, Apr 29, 2014 at 05:36:30PM +0100, Joel Fernandes wrote: [...] > >> Sorry what I meant is, say its of Type function. What tells the firmware > >> to switch to THUMB? > >> > >> What's typically done is a boot address register is written by the > >> kernel, and the firmware jumps to it after WFE. > > > > Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker > > for x to have the Thumb bit set if the code is Thumb. > > > > This means that any reference the linker fixes up for that symbol > > will have the Thumb bit set appropriately. This applies to any kind > > of reference, so code in another file that takes the address of the > > symbol and then passes that address to the firmware should result in the > > firmware getting an address with the Thumb bit. > > > > From the firmware's point of view it just gets a raw address, but > > the Thumb bit will now be set. The firmware still needs to handle > > this correctly when jumping, but from the look of the code this may > > already work on omap3/4. It would be interesting to know whether it > > works on omap5. > > Thanks a lot for the explanation. That makes perfect sense. I will try it and > let you know if it works on OMAP5. ARM/thumb interworking making perfect sense? I'll have to frame that and put it on the wall :) objdump and nm conveniently mask off the Thumb bit from all function addresses they print out, but if you show the symbols using readelf instead you'll see addresses with bit 0 set for Thumb functions. It's possible that the firmware still doesn't handle branching to Thumb correctly, but if it does it would be nice to remove the requirement to build an odd piece of a Thumb-2 kernel in ARM. Cheers ---Dave -- 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 06/23] ARM: OMAP: add OMAP5 DSI muxing
* Tomi Valkeinen [140429 09:33]: > On 29/04/14 19:19, Tomi Valkeinen wrote: > > On 29/04/14 18:05, Tony Lindgren wrote: > > > >>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives > >>> a raw regmap to its memory area, the driver needs to know about the OMAP > >>> control registers to use it. > >> > >> That would be probably best set up the same way we have already set up > >> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can > >> access it using regmap, see how drivers/regulator/pbias-regulator.c > >> sets up the pbias regulator with regmap for MMC. > > > > Right, but it means that the driver will contain platform specific code > > for all the omap revisions it supports. Isn't that wrong? > > > > I already have a patch for DSI that uses the syscon-method, and it works > > fine. But it's quite ugly, imo, to fiddle with the OMAP control > > registers in a driver. Anything using the system control module registers should be a separate driver. And it should ideally be implemeting some Linux generic framework that the consumer driver can then use. That leaves out the need to export custom functions. I guess we don't have a PHY framework for displays though, so how about just a separate minimal driver under drivers/video/omap2 that uses the syscon? > Oh, also, if I do that, I need to know both the SoC version and the DSS > version in the driver. Don't you get all you need in the compatible string? Something like compatible ti,dss-phy-omap5? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
> On Apr 29, 2014, at 2:17 AM, Dave Martin wrote: > >> On Mon, Apr 28, 2014 at 06:21:49PM +0100, Joel Fernandes wrote: >>> On 04/28/2014 12:20 PM, Joel Fernandes wrote: On 04/28/2014 11:43 AM, Dave Martin wrote: > On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote: > On my DRA7 system, when the kernel is built in THUMB mode, the secondary > CPU > (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. > This > seems to be because the CPU is in ARM mode once the ROM hands over > control to > the kernel. Switch to THUMB mode if required once the kernel is control > of > secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode > on > entry so this is not required and SMP boot works as is. > > Cc: Santosh Shilimkar > Cc: Russell King > Cc: Nishanth Menon > Cc: Tony Lindgren > Signed-off-by: Joel Fernandes > --- > arch/arm/mach-omap2/omap-headsmp.S |8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap-headsmp.S > b/arch/arm/mach-omap2/omap-headsmp.S > index 75e9295..1809dce 100644 > --- a/arch/arm/mach-omap2/omap-headsmp.S > +++ b/arch/arm/mach-omap2/omap-headsmp.S > @@ -1,7 +1,7 @@ > /* > * Secondary CPU startup routine source file. > * > - * Copyright (C) 2009 Texas Instruments, Inc. > + * Copyright (C) 2014 Texas Instruments, Inc. > * > * Author: > * Santosh Shilimkar > @@ -28,9 +28,13 @@ > * code. This routine also provides a holding flag into which > * secondary core is held until we're ready for it to initialise. > * The primary core will update this flag using a hardware > -+ * register AuxCoreBoot0. > + * register AuxCoreBoot0. > */ > ENTRY(omap5_secondary_startup) Are you sure this problem is not caused by the missing ENDPROC() for omap5_secondary_startup? You have END() instead (which may have been accidental). Without ENDPROC(), the symbol is not marked as a function and so the Thumb bit won't be set when taking a pointer -- so the kernel is actually telling the firmware to enter in ARM state. Try changing END() to ENDPROC() without this patch, and see if it makes a difference. If it still doesn't work, then the firmware either doesn't support entering in ARM, or is buggy. >>> >>> Thanks for the suggestion. I'm guessing what you mean is with ENDPROC, >>> interworking code uses bx instead of bl to set thumb mode. >>> >>> But ROM/firmware doesn't have access to symbol table, how would it know >>> the type of the symbol to be ARM or THUMB before it branches? >> Sorry what I meant is, say its of Type function. What tells the firmware >> to switch to THUMB? >> >> What's typically done is a boot address register is written by the >> kernel, and the firmware jumps to it after WFE. > > Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker > for x to have the Thumb bit set if the code is Thumb. > > This means that any reference the linker fixes up for that symbol > will have the Thumb bit set appropriately. This applies to any kind > of reference, so code in another file that takes the address of the > symbol and then passes that address to the firmware should result in the > firmware getting an address with the Thumb bit. > > From the firmware's point of view it just gets a raw address, but > the Thumb bit will now be set. The firmware still needs to handle > this correctly when jumping, but from the look of the code this may > already work on omap3/4. It would be interesting to know whether it > works on omap5. Thanks a lot for the explanation. That makes perfect sense. I will try it and let you know if it works on OMAP5. Regards, -Joel > > Cheers > ---Dave > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
On 29/04/14 19:19, Tomi Valkeinen wrote: > On 29/04/14 18:05, Tony Lindgren wrote: > >>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives >>> a raw regmap to its memory area, the driver needs to know about the OMAP >>> control registers to use it. >> >> That would be probably best set up the same way we have already set up >> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can >> access it using regmap, see how drivers/regulator/pbias-regulator.c >> sets up the pbias regulator with regmap for MMC. > > Right, but it means that the driver will contain platform specific code > for all the omap revisions it supports. Isn't that wrong? > > I already have a patch for DSI that uses the syscon-method, and it works > fine. But it's quite ugly, imo, to fiddle with the OMAP control > registers in a driver. Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
On 29/04/14 18:51, Felipe Balbi wrote: > On Thu, Apr 24, 2014 at 11:44:58AM -0700, Tony Lindgren wrote: >> * Felipe Balbi [140424 11:29]: >>> Hi, >>> >>> On Fri, Jan 17, 2014 at 09:44:59AM +0200, Tomi Valkeinen wrote: omap2_dpll_round_rate() doesn't actually round the given rate, even if the name and the description so hints. Instead it only tries to find an exact rate match, or if that fails, return ~0 as an error. What this basically means is that the user of the clock needs to know what rates the dpll can support, which obviously isn't right. This patch adds a simple method of rounding: during the iteration, the code keeps track of the closest rate match. If no exact match is found, the closest is returned. Signed-off-by: Tomi Valkeinen >>> >>> Tony, looks like this patch was lost. Are you taking it during the -rc ? >> >> Would like to hear what Paul thinks of the updated patch suggested >> by Tomi first. > > Paul, any chance you can review Tomi's v2 ? It'd be very nice to get > display working on BBB. Btw, I'm fine with my v2 patch, but I think the original one is fine also. It's true that the original patch changes the dpll behavior when an exact match is not found. However, I think our drivers always request an exact match, and in that case the original patch doesn't change the behavior in practice. In theory it's possible that a driver requests a non-exact clock from the dpll, and when it gets an error, it does something else. But, if I'm not mistaken, all our dplls have a clk-divider after them. And as clk-divider doesn't handle the error from dpll in any way, and instead returns bogus rates, I presume all our drivers use exact clocks. So v2 is perhaps slightly safer option, but I'm not sure if the added complexity (even if quite small) is worth it. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
On 29/04/14 18:05, Tony Lindgren wrote: >> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives >> a raw regmap to its memory area, the driver needs to know about the OMAP >> control registers to use it. > > That would be probably best set up the same way we have already set up > for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can > access it using regmap, see how drivers/regulator/pbias-regulator.c > sets up the pbias regulator with regmap for MMC. Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong? I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On 04/28/2014 06:02 PM, Simon Horman wrote: > On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: >> Since we now automatically enable early BRESP in core L2C-310 code when >> we detect a Cortex-A9, we don't need platforms/SoCs to set this bit >> explicitly. Instead, they should seek to preserve the value of bit 30 >> in the auxiliary control register. >> >> Acked-by: Tony Lindgren >> Signed-off-by: Russell King > > I would prefer if this patch was broken out into individual patches > for each board or SoC file and that they were then picked up > by their respective platform maintainers. > > Likewise for patch 66/97. Although it is only for shmobile > I would prefer it broken out. There are far too many dependencies in this series to break out the board file patches to be merged separately; it'd take either a whole bunch of kernel releases to merge it all that way, or a twisty maze of tiny topic branches cross-merged all over the place. Neither option is realistic. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] phy: omap-usb2: Use generic clock names "wkupclk" and "refclk"
On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: > On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: > > +Nishant > > > > Hi, > > > > On 04/28/2014 07:03 PM, Felipe Balbi wrote: > > > Hi, > > > > > > On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: > > >> As clocks might be named differently on multiple platforms, use a generic > > >> name in the driver and allow device tree node to specify the platform > > >> specific clock name. > > >> > > >> Signed-off-by: Roger Quadros > > >> --- > > >> drivers/phy/phy-omap-usb2.c | 8 > > >> 1 file changed, 4 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c > > >> index a2205a8..fb5e515 100644 > > >> --- a/drivers/phy/phy-omap-usb2.c > > >> +++ b/drivers/phy/phy-omap-usb2.c > > >> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device > > >> *pdev) > > >> if (IS_ERR(phy_provider)) > > >> return PTR_ERR(phy_provider); > > >> > > >> -phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); > > >> +phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); > > > > > > doesn't this patch cause a regression ? I mean, you're changing the > > > clock name before fixing DTS. Also, that DTS has been in a major version > > > of the kernel, so we need to maintain compatibility with it. How about: > > > > I'm changing the DTS in Patch 4, but I prefer to do it in this patch > > to prevent synchronization issues in -next. > > > > About backward compatibility, I agree with you but at the same time I > > don't think anyone using TI SoCs burns the DTB to ROM and needs > > backward compatibility. We supply our BSPs/SDKs with the updated DTBs. > > Do you feel strict backward compatibility is worth the effort for TI > > specific blocks? > > dunno, but it would, at least, avoid "synchronization issues with > linux-next" :-) and the bisectability issue. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 3/7] phy: omap-usb2: Use generic clock names "wkupclk" and "refclk"
On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: > +Nishant > > Hi, > > On 04/28/2014 07:03 PM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: > >> As clocks might be named differently on multiple platforms, use a generic > >> name in the driver and allow device tree node to specify the platform > >> specific clock name. > >> > >> Signed-off-by: Roger Quadros > >> --- > >> drivers/phy/phy-omap-usb2.c | 8 > >> 1 file changed, 4 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c > >> index a2205a8..fb5e515 100644 > >> --- a/drivers/phy/phy-omap-usb2.c > >> +++ b/drivers/phy/phy-omap-usb2.c > >> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device > >> *pdev) > >>if (IS_ERR(phy_provider)) > >>return PTR_ERR(phy_provider); > >> > >> - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); > >> + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); > > > > doesn't this patch cause a regression ? I mean, you're changing the > > clock name before fixing DTS. Also, that DTS has been in a major version > > of the kernel, so we need to maintain compatibility with it. How about: > > I'm changing the DTS in Patch 4, but I prefer to do it in this patch > to prevent synchronization issues in -next. > > About backward compatibility, I agree with you but at the same time I > don't think anyone using TI SoCs burns the DTB to ROM and needs > backward compatibility. We supply our BSPs/SDKs with the updated DTBs. > Do you feel strict backward compatibility is worth the effort for TI > specific blocks? dunno, but it would, at least, avoid "synchronization issues with linux-next" :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: debugfs: add snapshot to dump requests trbs events
Hi,
On Tue, Apr 29, 2014 at 05:21:42PM -0400, Zhuang Jin Can wrote:
> On Mon, Apr 28, 2014 at 10:55:36AM -0500, Felipe Balbi wrote:
> > On Mon, Apr 28, 2014 at 04:49:23PM -0400, Zhuang Jin Can wrote:
> > > Adds a debugfs file "snapshot" to dump dwc3 requests, trbs and events.
> >
> > you need to explain what are you trying to provide to our users here.
> >
> > What "problem" are you trying to solve ?
> >
> The interface enables users to easily peek into requests, trbs and
> events to know the current transfer state of each request.
> If an transfer is stuck, user can use the interface to check why it's
> stuck (e.g. Is it because a gadget doesn't queued the request? Or it's
> queued but it's not primed to the controller? Or It's primed to the
> controller but the TRBs and events indicate the transfer never completes?).
> User can immediately narrow down the issue without enabling verbose log or
> reproduce the issue again. It's helpful when we need to deal with some
> hard-to-reproduce bugs or timing sensitive bugs can't be reproduced with
> verbose log enabled.
this should be part of the commit log in some shape or form.
> > > As ep0 requests are more complex than others. It's not included in this
> > > patch.
> >
> > For ep0, you could at least print the endpoint phase we are currently
> > in and if we have requests in flight or not.
> >
> Agree. Will add it in [PATCH v2].
tks
> > > + seq_puts(s, "busy_slot--|\n");
> > > + seq_puts(s, " \\\n");
> > > + }
> > > + if (i == (dep->free_slot & DWC3_TRB_MASK)) {
> > > + seq_puts(s, "free_slot--|\n");
> > > + seq_puts(s, " \\\n");
> > > + }
> > > + seq_printf(s, "trb[%02d](dma@0x%pad): %08x(bpl), %08x(bph),
> > > %08x(size), %08x(ctrl)\n",
> >
> > I'm not sure you need to print out the TRB address. bpl, bph, size and
> > ctrl are desired though.
> >
> printing out the TRB DMA address helps user to locate the start TRB of a
> request. I admit that we can achive the same purose using the "start_slot"
> of the request. I'll remove it in [PATCH v2].
thanks
> > > + i, &dep->trb_pool_dma + i * sizeof(*trb),
> > > + trb->bpl, trb->bph, trb->size, trb->ctrl);
> >
> > this will be pretty difficult to parse by a human. I would rather see
> > you creating one directory per TRB (and also one directory per
> > endpoint) which holds the details for that entity, so that it looks
> > like:
> >
> > dwc3
> > |-- current_state (or perhaps a better name, but snapshot isn't very good
> > either)
> Actually, it's hard to find a perfect name. "current_state" or "snapshot"
> doesn't
> make too much difference to me. If "current_state" makes more sense to you, I
> can change to use this name. Or let me know if you have a better suggestion.
the name is important as we will have to deal with it for the next 50
years. We also need to think about someone starting out on dwc3 5 years
from now or a QA engineer in whatever OEM trying to provide details of
the failure for the development team. It needs to be well thought out.
I don't have a better idea but snapshot gives me the idea that we will
end up with a copy of everything which we can revisit at any time and
that's not true. If we read this file twice there's no guarantee it'll
contain the same information.
> > |-- ep2
> > | |-- direction
> > | |-- maxpacket
> > | |-- number
> > | |-- state
> > | |-- stream_capable
> > | |-- type
> > | |-- trbs
> > | | |-- trb0
> > | | | |-- bph
> > | | | |-- bpl
> > | | | |-- ctrl
> > | | | |-- size
> > | | |-- trb1
> > | | | |-- bph
> > | | | |-- bpl
> > | | | |-- ctrl
> > | | | |-- size
> > | | |-- trb2
> > | | | |-- bph
> > | | | |-- bpl
> > | | | |-- ctrl
> > | | | |-- size
> > | | |-- trb3
> > | | | |-- bph
> > | | | |-- bpl
> > | | | |-- ctrl
> > | | | |-- size
> > . . .
> > . . .
> > . . .
> > | |-- request0
> > | | |-- direction
> > | | |-- mapped
> > | | |-- queued
> > | | |-- trb0(symlink to actual trb directory)
> > | | |-- ep2 (symlink to actual ep2 directory)
> > | | |-- usbrequest
> > | | |-- actual
> > | | |-- length
> > | | |-- no_interrupt
> > | | |-- num_mapped_sgs
> > | | |-- num_sgs
> > | | |-- short_not_ok
> > | | |-- status
> > | | |-- stream_id
> > | | |-- zero
> > | |-- request1
> > | | |-- direction
> > | | |-- mapped
> > | | |-- queued
> > | | |-- trb1(symlink to actual trb directory)
> > | | |-- ep2 (symlink to actu
Re: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
On Thu, Apr 24, 2014 at 11:44:58AM -0700, Tony Lindgren wrote: > * Felipe Balbi [140424 11:29]: > > Hi, > > > > On Fri, Jan 17, 2014 at 09:44:59AM +0200, Tomi Valkeinen wrote: > > > omap2_dpll_round_rate() doesn't actually round the given rate, even if > > > the name and the description so hints. Instead it only tries to find an > > > exact rate match, or if that fails, return ~0 as an error. > > > > > > What this basically means is that the user of the clock needs to know > > > what rates the dpll can support, which obviously isn't right. > > > > > > This patch adds a simple method of rounding: during the iteration, the > > > code keeps track of the closest rate match. If no exact match is found, > > > the closest is returned. > > > > > > Signed-off-by: Tomi Valkeinen > > > > Tony, looks like this patch was lost. Are you taking it during the -rc ? > > Would like to hear what Paul thinks of the updated patch suggested > by Tomi first. Paul, any chance you can review Tomi's v2 ? It'd be very nice to get display working on BBB. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
* Tomi Valkeinen [140428 22:26]: > On 28/04/14 19:45, Tony Lindgren wrote: > > * Tomi Valkeinen [140427 23:53]: > >> On 25/04/14 18:31, Tony Lindgren wrote: > >> > >>> Chances are any mux register in the syscon area already works with > >>> pinctrl-single,pins or pinctrl-single,bits option. The ones in the > >>> padconf area should be already mapped so the driver just has to > >>> request them. > >> > >> If using the padconf (say omap4_padconf_global for omap4), doesn't that > >> mean we need to have platform specific bits in the driver? Isn't that > >> something we've been trying to remove all the time? > > > > No, it's all done in a Linux generic way during driver probe, see > > drivers/base/pinctrl.c. You just need to define the default pins > > in the .dts files. If you need dynamic remuxing in the driver, > > you can define other named states that the driver can then toggle > > with pinctrl_select_state(). > > omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives > a raw regmap to its memory area, the driver needs to know about the OMAP > control registers to use it. That would be probably best set up the same way we have already set up for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can access it using regmap, see how drivers/regulator/pbias-regulator.c sets up the pbias regulator with regmap for MMC. > Pinctrl-single cannot be used for CONTROL_DSIPHY register, as the > register contents are a bit funny and DSI1 and DSI2 bits are mixed > together. And CONTROL_DSIPHY is already in the memory region defined by > the omap4_padconf_global, so I guess it wouldn't be good to map parts of > the same memory region in a pinctrl node. If it's more than a mux, then it should not be set up as a pinctrl register. Looks like CONTROL_DSIPHY is already available for drivers via regmap as it falls into the *_padconf_global mappings for omap4 and omap5. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] arm: dts: am43x-clock: add tbclk data for ehrpwm.
On 04/29/2014 05:15 PM, Sourav Poddar wrote:
We need "tbclk" clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar
Acked-by: Tero Kristo
---
v2->v3
- correct bitshifting
arch/arm/boot/dts/am43xx-clocks.dtsi | 48 ++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..42d7b1f 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = <1>;
clock-div = <1>;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <0>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <1>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <2>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <4>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <5>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <6>;
+ reg = <0x0664>;
+ };
};
&prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, "func_12m_clk", "func_12m_clk"),
DT_CLK(NULL, "vtp_clk_div", "vtp_clk_div"),
DT_CLK(NULL, "usbphy_32khz_clkmux", "usbphy_32khz_clkmux"),
+ DT_CLK("48300200.ehrpwm", "tbclk", "ehrpwm0_tbclk"),
+ DT_CLK("48302200.ehrpwm", "tbclk", "ehrpwm1_tbclk"),
+ DT_CLK("48304200.ehrpwm", "tbclk", "ehrpwm2_tbclk"),
+ DT_CLK("48306200.ehrpwm", "tbclk", "ehrpwm3_tbclk"),
+ DT_CLK("48308200.ehrpwm", "tbclk", "ehrpwm4_tbclk"),
+ DT_CLK("4830a200.ehrpwm", "tbclk", "ehrpwm5_tbclk"),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am437x-gp-evm: Boot fixes
On 04/25/2014 11:41 AM, Tony Lindgren wrote: * Dave Gerlach [140423 10:25]: On 04/23/2014 09:59 AM, Tony Lindgren wrote: * Dave Gerlach [140422 12:53]: On 04/22/2014 02:01 PM, Tony Lindgren wrote: * Dave Gerlach [140422 11:52]: This patch, along with patch here [1], fixes boot for am437x-gp-evm. The bootloader configures gpio5_7 to control the DDR3 termination regulator, the linked patch prevents that gpio bank from being reset and losing the previously configured state, and this patch binds the gpio to a regulator so the kernel is aware of the state of the gpio. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg102941.html Setting up the GPIO regulator makes sense to me. But the hack in the link above is potentially a nasty time bomb for anybody trying to use GPIO bank 5 on that board. What tests have been done that the GPIO bank behaves properly when it's not reset? We've been using this configuration on this board for a while without any apparent issues. Also, am335x-evmsk already uses the same idea for the VTT regulator on board from commit 6046adb6ad701026c10adeac8d6a4138895f12e5 [ARM: dts: am335x-evmsk: Do not reset gpio0] and I am unaware of any issues with that either. OK. Do you have other GPIOs in use as interrupts for devices in these banks and do they work fine? I dont see any interrupts in use from gpio5 bank but as a quick test if I add ti,no-reset-on-init to gpio3 and gpio4 I see no issue with matrix-keypad operation which uses gpios from each of those banks. OK thanks for testing. I'll apply the ti,no-reset-on-init patch from [1] above into omap-for-v3.15/fixes-v2. The regulator patch can wait for v3.16, and should be also implemented for the am335x-evmsk the same way, so maybe add that too to your patch? Alright thanks, yes I can do that as well for v2. Regards, Dave Also, can you please test to make sure this works with the most recent Javier's GPIO patches that had the issue of not booting on am335x-evmsk? Yes, when using Javier's patches in addition to this patch [1], which was found to be necessary through this discussion [2], the AM437x GP EVM boots fine with linux-next with my regulator patch and gpio5 no reset patch applied. OK good to hear. Tony [1] https://patchwork.kernel.org/patch/4041881/ [2] http://marc.info/?t=139817273800014&r=1&w=2 Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3] arm: dts: am43x-clock: add tbclk data for ehrpwm.
We need "tbclk" clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar
---
v2->v3
- correct bitshifting
arch/arm/boot/dts/am43xx-clocks.dtsi | 48 ++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..42d7b1f 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = <1>;
clock-div = <1>;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <0>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <1>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <2>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <4>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <5>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <6>;
+ reg = <0x0664>;
+ };
};
&prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, "func_12m_clk", "func_12m_clk"),
DT_CLK(NULL, "vtp_clk_div", "vtp_clk_div"),
DT_CLK(NULL, "usbphy_32khz_clkmux", "usbphy_32khz_clkmux"),
+ DT_CLK("48300200.ehrpwm", "tbclk", "ehrpwm0_tbclk"),
+ DT_CLK("48302200.ehrpwm", "tbclk", "ehrpwm1_tbclk"),
+ DT_CLK("48304200.ehrpwm", "tbclk", "ehrpwm2_tbclk"),
+ DT_CLK("48306200.ehrpwm", "tbclk", "ehrpwm3_tbclk"),
+ DT_CLK("48308200.ehrpwm", "tbclk", "ehrpwm4_tbclk"),
+ DT_CLK("4830a200.ehrpwm", "tbclk", "ehrpwm5_tbclk"),
{ .node_name = NULL },
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 29 April 2014 06:09, Sebastian Andrzej Siewior wrote: > On 04/29/2014 10:27 AM, George Cherian wrote: >> Hi Sebastian, > > Hi George, > >> On 4/29/2014 1:36 PM, Sebastian Andrzej Siewior wrote: >>> On 04/29/2014 09:58 AM, George Cherian wrote: >> This is easily fixed by moving the node at the beggining of the child >> list, >> so it's probed first. This will give issues on module removal. Since we use device_for_each_child in remove patch, it will try to remove cppi dma controller, while the channel is still in use by musb node. >>> Isn't this currently disabled because it blew up in the phy code? >> Yes. So how if the dt looks like this > > No. I remember we talked about this and we decided not to duct tape the > bug by moving the nodes around. Instead we wanted to disable the child > removal part (one tiny module that can't be removed) until the PHY code > does no longer blow up. > If the same case is for the DMA driver then it should be fixed, too. > The order of the nodes in .dts should not crash the kernel under any > circumstances. If a different node order accelerates the probing then > fine. But a crash is a no no. > I still don't see any reason to have the DMA controller node as a child of the USB. However, it seems we need it this way for now; at least until we get rid of the hwmod altogether. That said, this DT-ordering to fix other issues is starting to seem a very bad idea. I'll prepare a v3 to leave the DT as it is, and instead force the driver to probe and remove the childs so the DMA is probed first and the removed last. We can always get rid of such workaround, once we can remove the DMA controller out of the USB - as it should be. -- Ezequiel GarcÃa, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/20] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On Monday 28 April 2014 08:44 PM, Nishanth Menon wrote: > V3: has the following changes (w.r.t v2): > - fixed relaxed commit message and usage. > - AM437x internal documents showed that: > - new master information updated into the data > - masterid register definition is different from OMAP4-DRA7 - > some > additional parsing is done in hardware to "avoid s/w parsing" > - Additional testing information showed logic fail for masking > "unclearable" > new patch added to series - patch #15 > - Picked up previous acks and tested by - minor changes verified Tested the series on AM437x ePOS EVM and works great. Tested-by: Sekhar Nori Thanks, Sekhar -- 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/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman wrote: > Geert Uytterhoeven writes: > > > When adding a device from DT, check if its clocks are suitable for Runtime > > PM, and register them with the PM core. > > If Runtime PM is disabled, just enable the clock. > > > > This allows the PM core to automatically manage gate clocks of devices for > > Runtime PM. > > ...unless the device is already in an existing pm_domain, right? > > I like this approach, and it extends nicely what we already do on > platforms using drivers/base/power/clock_ops.c into DT land. > > My only concern is how this will interact if it's used along with > devices that have existing pm_domains. I don't have any specific > concerns (yet, because it's Friday, and my brain is turing off), but it > just made me wonder if this will be potentially confusing. I have big concerns about this approach. First, it will only work if a clock is available at deivce creation time. The conversion of irq controllers to normal device drivers has already shown that is a bad idea. I also don't like that it tries to set up every clock, but there is no guarantee that the driver will even use it. I would rather see this behaviour linked into the function that obtains the clock at driver .probe() time. That way it can handle deferred probe correctly and it only sets up clocks that are actually used by the driver. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] arm: dts: am43x-clock: add tbclk data for ehrpwm.
Hi Tero,
On Tuesday 29 April 2014 06:16 PM, Tero Kristo wrote:
On 04/29/2014 11:34 AM, Sourav Poddar wrote:
We need "tbclk" clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar
---
v1->v2:
change compatible according to mainline.
arch/arm/boot/dts/am43xx-clocks.dtsi | 48
++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..401 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = <1>;
clock-div = <1>;
};
+
+ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
+#clock-cells = <0>;
+compatible = "ti,gate-clock";
+clocks = <&dpll_per_m2_ck>;
+ti,bit-shift = <0>;
+reg = <0x0664>;
+};
+
+ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
+#clock-cells = <0>;
+compatible = "ti,gate-clock";
+clocks = <&dpll_per_m2_ck>;
+ti,bit-shift = <1>;
+reg = <0x0664>;
+};
+
+ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
+#clock-cells = <0>;
+compatible = "ti,gate-clock";
+clocks = <&dpll_per_m2_ck>;
+ti,bit-shift = <2>;
+reg = <0x0664>;
+};
+
+ehrpwm3_tbclk: ehrpwm3_tbclk@44e10664 {
+#clock-cells = <0>;
+compatible = "ti,gate-clock";
+clocks = <&dpll_per_m2_ck>;
+ti,bit-shift = <3>;
+reg = <0x0664>;
+};
+
+ehrpwm4_tbclk: ehrpwm4_tbclk@44e10664 {
+#clock-cells = <0>;
+compatible = "ti,gate-clock";
+clocks = <&dpll_per_m2_ck>;
+ti,bit-shift = <4>;
+reg = <0x0664>;
+};
+
+ehrpwm5_tbclk: ehrpwm5_tbclk@44e10664 {
+#clock-cells = <0>;
+compatible = "ti,gate-clock";
+clocks = <&dpll_per_m2_ck>;
+ti,bit-shift = <5>;
+reg = <0x0664>;
+};
Looking at the TRM, I guess pwm3, pwm4 and pwm5 bit-shifts are wrong?
Namely, bit 3 of the register is used for PWM_SYNCSEL instead of PWM3
clock enable. Is this correct and these should be fixed?
Yups, my bad. Used the bit shifts in continuation. Will send an updated
patch.
-Tero
};
&prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, "func_12m_clk", "func_12m_clk"),
DT_CLK(NULL, "vtp_clk_div", "vtp_clk_div"),
DT_CLK(NULL, "usbphy_32khz_clkmux", "usbphy_32khz_clkmux"),
+DT_CLK("48300200.ehrpwm", "tbclk", "ehrpwm0_tbclk"),
+DT_CLK("48302200.ehrpwm", "tbclk", "ehrpwm1_tbclk"),
+DT_CLK("48304200.ehrpwm", "tbclk", "ehrpwm2_tbclk"),
+DT_CLK("48306200.ehrpwm", "tbclk", "ehrpwm3_tbclk"),
+DT_CLK("48308200.ehrpwm", "tbclk", "ehrpwm4_tbclk"),
+DT_CLK("4830a200.ehrpwm", "tbclk", "ehrpwm5_tbclk"),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] arm: dts: am33xx-clock: Fix ehrpwm tbclk data.
On 04/29/2014 11:34 AM, Sourav Poddar wrote:
tbclk does not need to be a composite clock, we can simply
use gate clock for this purpose.
Signed-off-by: Sourav Poddar
Looks good to me so:
Acked-by: Tero Kristo
---
v1->v2:
change compatible string according to mainline.
arch/arm/boot/dts/am33xx-clocks.dtsi | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index 9ccfe50..712edce 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -96,47 +96,29 @@
clock-div = <1>;
};
- ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
#clock-cells = <0>;
- compatible = "ti,composite-no-wait-gate-clock";
+ compatible = "ti,gate-clock";
clocks = <&dpll_per_m2_ck>;
ti,bit-shift = <0>;
reg = <0x0664>;
};
- ehrpwm0_tbclk: ehrpwm0_tbclk {
- #clock-cells = <0>;
- compatible = "ti,composite-clock";
- clocks = <&ehrpwm0_gate_tbclk>;
- };
-
- ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
#clock-cells = <0>;
- compatible = "ti,composite-no-wait-gate-clock";
+ compatible = "ti,gate-clock";
clocks = <&dpll_per_m2_ck>;
ti,bit-shift = <1>;
reg = <0x0664>;
};
- ehrpwm1_tbclk: ehrpwm1_tbclk {
- #clock-cells = <0>;
- compatible = "ti,composite-clock";
- clocks = <&ehrpwm1_gate_tbclk>;
- };
-
- ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
#clock-cells = <0>;
- compatible = "ti,composite-no-wait-gate-clock";
+ compatible = "ti,gate-clock";
clocks = <&dpll_per_m2_ck>;
ti,bit-shift = <2>;
reg = <0x0664>;
};
-
- ehrpwm2_tbclk: ehrpwm2_tbclk {
- #clock-cells = <0>;
- compatible = "ti,composite-clock";
- clocks = <&ehrpwm2_gate_tbclk>;
- };
};
&prcm_clocks {
clk_32768_ck: clk_32768_ck {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] arm: dts: am43x-clock: add tbclk data for ehrpwm.
On 04/29/2014 11:34 AM, Sourav Poddar wrote:
We need "tbclk" clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar
---
v1->v2:
change compatible according to mainline.
arch/arm/boot/dts/am43xx-clocks.dtsi | 48 ++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..401 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = <1>;
clock-div = <1>;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <0>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <1>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <2>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <3>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <4>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <5>;
+ reg = <0x0664>;
+ };
Looking at the TRM, I guess pwm3, pwm4 and pwm5 bit-shifts are wrong?
Namely, bit 3 of the register is used for PWM_SYNCSEL instead of PWM3
clock enable. Is this correct and these should be fixed?
-Tero
};
&prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, "func_12m_clk", "func_12m_clk"),
DT_CLK(NULL, "vtp_clk_div", "vtp_clk_div"),
DT_CLK(NULL, "usbphy_32khz_clkmux", "usbphy_32khz_clkmux"),
+ DT_CLK("48300200.ehrpwm", "tbclk", "ehrpwm0_tbclk"),
+ DT_CLK("48302200.ehrpwm", "tbclk", "ehrpwm1_tbclk"),
+ DT_CLK("48304200.ehrpwm", "tbclk", "ehrpwm2_tbclk"),
+ DT_CLK("48306200.ehrpwm", "tbclk", "ehrpwm3_tbclk"),
+ DT_CLK("48308200.ehrpwm", "tbclk", "ehrpwm4_tbclk"),
+ DT_CLK("4830a200.ehrpwm", "tbclk", "ehrpwm5_tbclk"),
{ .node_name = NULL },
};
--
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] gpio: always enable GPIO_OMAP on ARCH_OMAP
On Tuesday 29 April 2014 12:53:45 Javier Martinez Canillas wrote: > Hello Arnd, > > On 04/29/2014 12:26 PM, Arnd Bergmann wrote: > > On Tuesday 29 April 2014 01:59:20 Javier Martinez Canillas wrote: > >> This driver is also used by OMAP1. Even when disabling GPIO_OMAP on that > >> platform doesn't cause a build error since no function defined in the > >> driver is > >> used directly by platform code, I think that we always want this driver on > >> OMAP1 > >> too. > >> > >> > However, it seems entirely reasonable to include the driver in build > >> > tests > >> > on other platforms, so we should also allow building it for COMPILE_TEST > >> > builds and select the required GENERIC_IRQ_CHIP that may not already be > >> > enabled on other platforms. > >> > > >> > Signed-off-by: Arnd Bergmann > >> > > >> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > >> > index c58b828..c8c42be 100644 > >> > --- a/drivers/gpio/Kconfig > >> > +++ b/drivers/gpio/Kconfig > >> > @@ -244,9 +244,10 @@ config GPIO_OCTEON > >> > family of SOCs. > >> > > >> > config GPIO_OMAP > >> > - bool "TI OMAP GPIO support" > >> > + bool "TI OMAP GPIO support" if COMPILE_TEST && !ARCH_OMAP2PLUS > >> > >> So this should be: > >> > >> + bool "TI OMAP GPIO support" if COMPILE_TEST && !ARCH_OMAP2PLUS && > >> !ARCH_OMAP1 > >> > > > > Well, if COMPILE_TEST is disabled on OMAP1, the option is already > > hidden and enabled in my version. It seems reasonable to me to > > allow compile-testing OMAP1 without the GPIO driver, while a kernel > > running on OMAP1 should always have COMPILE_TEST disabled. > > > > I understand your point. I thought you also wanted to be sure that the option > will be hidden in platforms where it make sense to always enable GPIO_OMAP > even > if COMPILE_TEST is enabled. I thought about that, but didn't want to enforce it without a good reason when your original patch had just made it possible to disable the option. > If the idea of this patch is to only avoid build errors when GPIO_OMAP is > disabled and allowing build testing the driver in other platforms, then I'm ok > with your patch and feel free to add my Acked-by tag. Ok, thanks! > And you are right that COMPILE_TEST is disabled in omap1_defconfig and after > all > there are so many drivers needed for a platform to be usable on boot. So one > has > to take care of enabling all the needed options as long as there isn't a > combination that cause a build error like the one you are fixing here. Ok Arnd -- 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 5/5] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
On Tuesday 29 April 2014 16:35:13 Rajendra Nayak wrote:
> @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>
> #if defined(CONFIG_SOC_DRA7XX)
> #undef soc_is_dra7xx
> +#undef soc_is_dra74x
> +#undef soc_is_dra72x
> #define soc_is_dra7xx()(of_machine_is_compatible("ti,dra7"))
> +#define soc_is_dra74x()(of_machine_is_compatible("ti,dra74"))
> +#define soc_is_dra72x()(of_machine_is_compatible("ti,dra72"))
> +
You shouldn't normally have to define these. Why are they needed?
Maybe it's better to wait for a user to show up, and then we can decide
whether we actually want to have them this way, or if there is a better
solution for the particular use case.
Normally, we'd want to make run-time decisions based on properties
of the nodes a driver is working on, not the global machine compatible
string.
Arnd
--
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 5/5] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
On Tuesday 29 April 2014 04:48 PM, Arnd Bergmann wrote:
> On Tuesday 29 April 2014 16:35:13 Rajendra Nayak wrote:
>> @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>>
>> #if defined(CONFIG_SOC_DRA7XX)
>> #undef soc_is_dra7xx
>> +#undef soc_is_dra74x
>> +#undef soc_is_dra72x
>> #define soc_is_dra7xx()(of_machine_is_compatible("ti,dra7"))
>> +#define soc_is_dra74x()(of_machine_is_compatible("ti,dra74"))
>> +#define soc_is_dra72x()(of_machine_is_compatible("ti,dra72"))
>> +
>
> You shouldn't normally have to define these. Why are they needed?
>
> Maybe it's better to wait for a user to show up, and then we can decide
> whether we actually want to have them this way, or if there is a better
> solution for the particular use case.
>
> Normally, we'd want to make run-time decisions based on properties
> of the nodes a driver is working on, not the global machine compatible
> string.
Yeah, actually this can be dropped. There is no user for it now.
>
> Arnd
>
--
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/15] ASoC: Amstrad E3 needs TTY support for codec
From: Arnd Bergmann The cx20442 codec driver used here requires the TTY layer to be enabled, or we get a link error: sound/built-in.o: In function `cx20442_codec_remove': cx20442.c:398: undefined reference to `tty_hangup' sound/built-in.o: In function `ams_delta_remove': ams-delta.c:613: undefined reference to `tty_unregister_ldisc' sound/built-in.o: In function `ams_delta_cx20442_init': ams-delta.c:559: undefined reference to `tty_register_ldisc' This adds the missing dependency in the E3 configuration, there was already one for the codec. Signed-off-by: Arnd Bergmann Signed-off-by: Xia Kaixu Cc: Mark Brown Cc: Liam Girdwood Cc: Peter Ujfalusi Cc: Jarkko Nikula Cc: linux-omap@vger.kernel.org Cc: alsa-de...@alsa-project.org --- sound/soc/omap/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 2796af9..d44463a 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -37,7 +37,7 @@ config SND_OMAP_SOC_RX51 config SND_OMAP_SOC_AMS_DELTA tristate "SoC Audio support for Amstrad E3 (Delta) videophone" - depends on SND_OMAP_SOC && MACH_AMS_DELTA + depends on SND_OMAP_SOC && MACH_AMS_DELTA && TTY select SND_OMAP_SOC_MCBSP select SND_SOC_CX20442 help -- 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 06/15] ASoC: RX-51 audio needs I2C
From: Arnd Bergmann The codec requires I2C to be enabled, so any other option that selects it should also depend on I2C. Signed-off-by: Arnd Bergmann Signed-off-by: Xia Kaixu Cc: Mark Brown Cc: Liam Girdwood Cc: Peter Ujfalusi Cc: Jarkko Nikula Cc: alsa-de...@alsa-project.org Cc: linux-omap@vger.kernel.org --- sound/soc/omap/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index e006593..2796af9 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -26,7 +26,7 @@ config SND_OMAP_SOC_N810 config SND_OMAP_SOC_RX51 tristate "SoC Audio support for Nokia RX-51" - depends on SND_OMAP_SOC && ARM && (MACH_NOKIA_RX51 || COMPILE_TEST) + depends on SND_OMAP_SOC && ARM && (MACH_NOKIA_RX51 || COMPILE_TEST) && I2C select SND_OMAP_SOC_MCBSP select SND_SOC_TLV320AIC3X select SND_SOC_TPA6130A2 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] ARM: dts: Add support for DRA72x family of devices
On Tuesday 29 April 2014 16:35:10 Rajendra Nayak wrote: > DRA722 is part of DRA72x family which are single core cortex A15 devices > with most infrastructure IPs otherwise same as whats on the DRA74x family. > > So move the cpu nodes into dra74x.dtsi and dra72x.dtsi respectively. > > Also add a minimal dra72-evm dts file. > > Signed-off-by: Rajendra Nayak > Cc: linux-...@vger.kernel.org > Cc: devicet...@vger.kernel.org Acked-by: Arnd Bergmann -- 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 4/5] ARM: OMAP2+: Add machine entry for dra72x devices
On Tuesday 29 April 2014 16:35:12 Rajendra Nayak wrote: > The only difference from the dra74x devices is the missing .smp entry. > > Signed-off-by: Rajendra Nayak > --- > arch/arm/mach-omap2/board-generic.c | 25 + > 1 file changed, 21 insertions(+), 4 deletions(-) > Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/5] ARM: OMAP2+: Add machine entry for dra72x devices
The only difference from the dra74x devices is the missing .smp entry.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/board-generic.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 90dbfdf..238ab0a 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -240,13 +240,13 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_DRA7XX
-static const char *dra7xx_boards_compat[] __initconst = {
- "ti,dra7xx",
+static const char *dra74x_boards_compat[] __initconst = {
+ "ti,dra742",
"ti,dra7",
NULL,
};
-DT_MACHINE_START(DRA7XX_DT, "Generic DRA7XX (Flattened Device Tree)")
+DT_MACHINE_START(DRA74X_DT, "Generic DRA74X (Flattened Device Tree)")
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap5_map_io,
@@ -255,7 +255,24 @@ DT_MACHINE_START(DRA7XX_DT, "Generic DRA7XX (Flattened
Device Tree)")
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
- .dt_compat = dra7xx_boards_compat,
+ .dt_compat = dra74x_boards_compat,
+ .restart= omap44xx_restart,
+MACHINE_END
+
+static const char *dra72x_boards_compat[] __initconst = {
+ "ti,dra722",
+ NULL,
+};
+
+DT_MACHINE_START(DRA72X_DT, "Generic DRA72X (Flattened Device Tree)")
+ .reserve= omap_reserve,
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_late = dra7xx_init_late,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra72x_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
#endif
--
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 v4 3/5] ARM: OMAP2+: Replace all __initdata with __initconst for const init
Use of const init definition must use __initconst so replace
all such instances where __initdata is used.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/board-generic.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index b8920b6..90dbfdf 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -43,7 +43,7 @@ static void __init omap_generic_init(void)
}
#ifdef CONFIG_SOC_OMAP2420
-static const char *omap242x_boards_compat[] __initdata = {
+static const char *omap242x_boards_compat[] __initconst = {
"ti,omap2420",
NULL,
};
@@ -62,7 +62,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP2430
-static const char *omap243x_boards_compat[] __initdata = {
+static const char *omap243x_boards_compat[] __initconst = {
"ti,omap2430",
NULL,
};
@@ -81,7 +81,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP3
-static const char *omap3_boards_compat[] __initdata = {
+static const char *omap3_boards_compat[] __initconst = {
"ti,omap3430",
"ti,omap3",
NULL,
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device
Tree)")
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap36xx_boards_compat[] __initdata = {
+static const char *omap36xx_boards_compat[] __initconst = {
"ti,omap36xx",
NULL,
};
@@ -118,7 +118,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened
Device Tree)")
.restart= omap3xxx_restart,
MACHINE_END
-static const char *omap3_gp_boards_compat[] __initdata = {
+static const char *omap3_gp_boards_compat[] __initconst = {
"ti,omap3-beagle",
"timll,omap3-devkit8000",
NULL,
@@ -137,7 +137,7 @@ DT_MACHINE_START(OMAP3_GP_DT, "Generic OMAP3-GP (Flattened
Device Tree)")
.restart= omap3xxx_restart,
MACHINE_END
-static const char *am3517_boards_compat[] __initdata = {
+static const char *am3517_boards_compat[] __initconst = {
"ti,am3517",
NULL,
};
@@ -157,7 +157,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
-static const char *am33xx_boards_compat[] __initdata = {
+static const char *am33xx_boards_compat[] __initconst = {
"ti,am33xx",
NULL,
};
@@ -177,7 +177,7 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP4
-static const char *omap4_boards_compat[] __initdata = {
+static const char *omap4_boards_compat[] __initconst = {
"ti,omap4460",
"ti,omap4430",
"ti,omap4",
@@ -199,7 +199,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_OMAP5
-static const char *omap5_boards_compat[] __initdata = {
+static const char *omap5_boards_compat[] __initconst = {
"ti,omap5432",
"ti,omap5430",
"ti,omap5",
@@ -221,7 +221,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_AM43XX
-static const char *am43_boards_compat[] __initdata = {
+static const char *am43_boards_compat[] __initconst = {
"ti,am4372",
"ti,am43",
NULL,
@@ -240,7 +240,7 @@ MACHINE_END
#endif
#ifdef CONFIG_SOC_DRA7XX
-static const char *dra7xx_boards_compat[] __initdata = {
+static const char *dra7xx_boards_compat[] __initconst = {
"ti,dra7xx",
"ti,dra7",
NULL,
--
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 v4 5/5] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
Use the corresponding compatibles to identify the devices.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/soc.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 30abcc8..5ff724e 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -245,6 +245,8 @@ IS_AM_SUBCLASS(437x, 0x437)
#define soc_is_omap54xx() 0
#define soc_is_omap543x() 0
#define soc_is_dra7xx()0
+#define soc_is_dra74x()0
+#define soc_is_dra72x()0
#if defined(MULTI_OMAP2)
# if defined(CONFIG_ARCH_OMAP2)
@@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430)
#if defined(CONFIG_SOC_DRA7XX)
#undef soc_is_dra7xx
+#undef soc_is_dra74x
+#undef soc_is_dra72x
#define soc_is_dra7xx()(of_machine_is_compatible("ti,dra7"))
+#define soc_is_dra74x()(of_machine_is_compatible("ti,dra74"))
+#define soc_is_dra72x()(of_machine_is_compatible("ti,dra72"))
+
#endif
/* Various silicon revisions for omap2 */
--
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 v4 0/5] ARM: DRA7: Add support for DRA72x devices
changes in v4: -1- used full SoC names in compatibles eg "ti,dra742" and "ti,dra722" -2- Created a seperate patch for replacing __initdata with __initconst changes in v3: Removed wildcards from compatible strings and duplicates from .dt_compat strings as suggested by Arnd DRA72x devices are single core Cortex A15 devices belonging to the DRA7 family (Similar to the DRA74x devices which are dual core Cortex A15 based) The patches (based off 3.15-rc3) add minimal DT/kernel modifications to add boot support on DRA722 device reusing all the kernel data for DRA742 device. Rajendra Nayak (5): ARM: dts: dra7-evm: Remove the wrong and undocumented compatible ARM: dts: Add support for DRA72x family of devices ARM: OMAP2+: Replace all __initdata with __initconst for const init ARM: OMAP2+: Add machine entry for dra72x devices ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients .../devicetree/bindings/arm/omap/omap.txt | 12 -- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts |6 +-- arch/arm/boot/dts/dra7.dtsi| 27 arch/arm/boot/dts/dra72-evm.dts| 24 +++ arch/arm/boot/dts/dra72x.dtsi | 25 +++ arch/arm/boot/dts/dra74x.dtsi | 41 ++ arch/arm/mach-omap2/board-generic.c| 45 ++-- arch/arm/mach-omap2/soc.h |7 +++ 9 files changed, 142 insertions(+), 48 deletions(-) create mode 100644 arch/arm/boot/dts/dra72-evm.dts create mode 100644 arch/arm/boot/dts/dra72x.dtsi create mode 100644 arch/arm/boot/dts/dra74x.dtsi -- 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 v4 1/5] ARM: dts: dra7-evm: Remove the wrong and undocumented compatible
"ti,dra752" is neither documented nor correct, since the device is actually a
dra742 device as rightly documented in dt bindings.
Signed-off-by: Rajendra Nayak
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..7807429 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -11,7 +11,7 @@
/ {
model = "TI DRA7";
- compatible = "ti,dra7-evm", "ti,dra752", "ti,dra7";
+ compatible = "ti,dra7-evm", "ti,dra7";
memory {
device_type = "memory";
--
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 v4 2/5] ARM: dts: Add support for DRA72x family of devices
DRA722 is part of DRA72x family which are single core cortex A15 devices
with most infrastructure IPs otherwise same as whats on the DRA74x family.
So move the cpu nodes into dra74x.dtsi and dra72x.dtsi respectively.
Also add a minimal dra72-evm dts file.
Signed-off-by: Rajendra Nayak
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/arm/omap/omap.txt | 12 --
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts |6 +--
arch/arm/boot/dts/dra7.dtsi| 27 -
arch/arm/boot/dts/dra72-evm.dts| 24
arch/arm/boot/dts/dra72x.dtsi | 25
arch/arm/boot/dts/dra74x.dtsi | 41
7 files changed, 104 insertions(+), 34 deletions(-)
create mode 100644 arch/arm/boot/dts/dra72-evm.dts
create mode 100644 arch/arm/boot/dts/dra72x.dtsi
create mode 100644 arch/arm/boot/dts/dra74x.dtsi
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 36ede19..3bad259 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -80,7 +80,10 @@ SoCs:
compatible = "ti,omap5432", "ti,omap5"
- DRA742
- compatible = "ti,dra7xx", "ti,dra7"
+ compatible = "ti,dra742", "ti,dra74", "ti,dra7"
+
+- DRA722
+ compatible = "ti,dra722", "ti,dra72", "ti,dra7"
- AM4372
compatible = "ti,am4372", "ti,am43"
@@ -120,5 +123,8 @@ Boards:
- AM437x GP EVM
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
-- DRA7 EVM: Software Developement Board for DRA7XX
- compatible = "ti,dra7-evm", "ti,dra7"
+- DRA742 EVM: Software Developement Board for DRA742
+ compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
+
+- DRA722 EVM: Software Development Board for DRA722
+ compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..ff98a97 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -288,7 +288,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb \
am437x-gp-evm.dtb \
- dra7-evm.dtb
+ dra7-evm.dtb \
+ dra72-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcom-msm8660-surf.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 7807429..39b718a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -7,11 +7,11 @@
*/
/dts-v1/;
-#include "dra7.dtsi"
+#include "dra74x.dtsi"
/ {
- model = "TI DRA7";
- compatible = "ti,dra7-evm", "ti,dra7";
+ model = "TI DRA742";
+ compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7";
memory {
device_type = "memory";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..e27fec7 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -33,33 +33,6 @@
serial5 = &uart6;
};
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0>;
-
- operating-points = <
- /* kHzuV */
- 100 106
- 1176000 116
- >;
-
- clocks = <&dpll_mpu_ck>;
- clock-names = "cpu";
-
- clock-latency = <30>; /* From omap-cpufreq driver */
- };
- cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <1>;
- };
- };
-
timer {
compatible = "arm,armv7-timer";
interrupts = ,
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
new file mode 100644
index 000..5147023
--- /dev/null
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "dra72x.dtsi"
+
+/ {
+ model = "TI DRA722";
+ compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7";
+
+ memory {
+ device_type = "memory";
+ reg =
Re: [PATCH] gpio: always enable GPIO_OMAP on ARCH_OMAP
Hello Arnd, On 04/29/2014 12:26 PM, Arnd Bergmann wrote: > On Tuesday 29 April 2014 01:59:20 Javier Martinez Canillas wrote: >> This driver is also used by OMAP1. Even when disabling GPIO_OMAP on that >> platform doesn't cause a build error since no function defined in the driver >> is >> used directly by platform code, I think that we always want this driver on >> OMAP1 >> too. >> >> > However, it seems entirely reasonable to include the driver in build tests >> > on other platforms, so we should also allow building it for COMPILE_TEST >> > builds and select the required GENERIC_IRQ_CHIP that may not already be >> > enabled on other platforms. >> > >> > Signed-off-by: Arnd Bergmann >> > >> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig >> > index c58b828..c8c42be 100644 >> > --- a/drivers/gpio/Kconfig >> > +++ b/drivers/gpio/Kconfig >> > @@ -244,9 +244,10 @@ config GPIO_OCTEON >> > family of SOCs. >> > >> > config GPIO_OMAP >> > - bool "TI OMAP GPIO support" >> > + bool "TI OMAP GPIO support" if COMPILE_TEST && !ARCH_OMAP2PLUS >> >> So this should be: >> >> + bool "TI OMAP GPIO support" if COMPILE_TEST && !ARCH_OMAP2PLUS && >> !ARCH_OMAP1 >> > > Well, if COMPILE_TEST is disabled on OMAP1, the option is already > hidden and enabled in my version. It seems reasonable to me to > allow compile-testing OMAP1 without the GPIO driver, while a kernel > running on OMAP1 should always have COMPILE_TEST disabled. > > Arnd > I understand your point. I thought you also wanted to be sure that the option will be hidden in platforms where it make sense to always enable GPIO_OMAP even if COMPILE_TEST is enabled. If the idea of this patch is to only avoid build errors when GPIO_OMAP is disabled and allowing build testing the driver in other platforms, then I'm ok with your patch and feel free to add my Acked-by tag. And you are right that COMPILE_TEST is disabled in omap1_defconfig and after all there are so many drivers needed for a platform to be usable on boot. So one has to take care of enabling all the needed options as long as there isn't a combination that cause a build error like the one you are fixing here. Thanks a lot and 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] gpio: always enable GPIO_OMAP on ARCH_OMAP
On Tuesday 29 April 2014 01:59:20 Javier Martinez Canillas wrote: > This driver is also used by OMAP1. Even when disabling GPIO_OMAP on that > platform doesn't cause a build error since no function defined in the driver > is > used directly by platform code, I think that we always want this driver on > OMAP1 > too. > > > However, it seems entirely reasonable to include the driver in build tests > > on other platforms, so we should also allow building it for COMPILE_TEST > > builds and select the required GENERIC_IRQ_CHIP that may not already be > > enabled on other platforms. > > > > Signed-off-by: Arnd Bergmann > > > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > > index c58b828..c8c42be 100644 > > --- a/drivers/gpio/Kconfig > > +++ b/drivers/gpio/Kconfig > > @@ -244,9 +244,10 @@ config GPIO_OCTEON > > family of SOCs. > > > > config GPIO_OMAP > > - bool "TI OMAP GPIO support" > > + bool "TI OMAP GPIO support" if COMPILE_TEST && !ARCH_OMAP2PLUS > > So this should be: > > + bool "TI OMAP GPIO support" if COMPILE_TEST && !ARCH_OMAP2PLUS && > !ARCH_OMAP1 > Well, if COMPILE_TEST is disabled on OMAP1, the option is already hidden and enabled in my version. It seems reasonable to me to allow compile-testing OMAP1 without the GPIO driver, while a kernel running on OMAP1 should always have COMPILE_TEST disabled. Arnd -- 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 v10 1/5] mmc: omap_hsmmc: Enable SDIO interrupt
On Mon, Apr 28, 2014 at 9:40 AM, Andreas Fenkart wrote:
> 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 mwifiex
> connected to MMC3 with mwifiex 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
> , Steve Sakoman
>
> For now, only support SDIO interrupt if we are booted with
> a separate wake-irq configued via device tree. This is
> because omaps need the wake-irq for idle states, and some
> omaps need special quirks. And we don't want to add new
> legacy mux platform init code callbacks any longer as we
> are moving to DT based booting anyways.
>
> To use it, you need to specify the wake-irq using the
> interrupts-extended property.
>
> [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: Balaji T K
> Signed-off-by: Andreas Fenkart
> Signed-off-by: Tony Lindgren
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 272e0ee..700fb91 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -36,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -106,6 +108,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)
> @@ -140,7 +143,6 @@
> #define VDD_3V0300 /* 30 uV */
> #define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
>
> -#define AUTO_CMD23 (1 << 1)/* Auto CMD23 support */
> /*
> * One controller can have multiple slots, like on some omap boards using
> * omap.c controller driver. Luckily this is not currently done on any known
> @@ -194,6 +196,7 @@ struct omap_hsmmc_host {
> u32 sysctl;
> u32 capa;
> int irq;
> + int wake_irq;
> int use_dma, dma_ch;
> struct dma_chan *tx_chan;
> struct dma_chan *rx_chan;
> @@ -206,6 +209,9 @@ struct omap_hsmmc_host {
> int req_in_progress;
> unsigned long clk_rate;
> unsigned intflags;
> +#define AUTO_CMD23 (1 << 0)/* Auto CMD23 support */
> +#define HSMMC_SDIO_IRQ_ENABLED (1 << 1)/* SDIO irq enabled */
> +#define HSMMC_WAKE_IRQ_ENABLED (1 << 2)
> struct omap_hsmmc_next next_data;
> struct omap_mmc_platform_data *pdata;
> };
> @@ -510,27 +516,40 @@ 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);
> +
> + /* latch pending CIRQ, but don't signal MMC core */
> + 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)
> {
> - OMAP_HSMMC_WRITE(host->base, ISE, 0);
> - OMAP_HSMMC_WRITE(host->base, IE, 0);
> + u32 irq_mask = 0;
> + unsig
Re: [PATCHv3 2/5] Input: tsc2005: use dev_err for error messages
On Sat 2014-04-26 01:56:16, Sebastian Reichel wrote: > Change some dev_dbg() invocations to dev_err() ones, because they > are supposed to output error messages. > > Signed-off-by: Sebastian Reichel Reviewed-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/5] Input: tsc2005: add DT support
On Sat 2014-04-26 01:56:18, Sebastian Reichel wrote: > This adds DT support to the tsc2005 touchscreen > driver. > > Signed-off-by: Sebastian Reichel > @@ -100,6 +102,11 @@ >TSC2005_CFR2_AVG_7) > > #define MAX_12BIT0xfff > +#define TSC2005_DEF_X_FUZZ 4 > +#define TSC2005_DEF_Y_FUZZ 8 > +#define TSC2005_DEF_P_FUZZ 2 > +#define TSC2005_DEF_RESISTOR 280 > IMO using defines insteaed of plain numbers does not help readability much, but Reviewed-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 5/5] Documentation: dt: Document TSC2005 DT binding
On Sat 2014-04-26 01:56:19, Sebastian Reichel wrote: > Add devicetree binding documentation for TSC2005 touchscreen. > Reviewed-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 3/5] Input: tsc2005: convert driver to use devm_*
On Sat 2014-04-26 01:56:17, Sebastian Reichel wrote: > Simplify the driver by using managed resources for memory allocation of > internal struct, input device allocation and irq request. > > Signed-off-by: Sebastian Reichel Reviewed-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/5] Input: add common DT binding for touchscreens
On Sat 2014-04-26 01:56:15, Sebastian Reichel wrote: > Add common DT binding documentation for touchscreen devices and > implement input_parse_touchscreen_of_params, which parses the common > properties and configures the input device accordingly. > > The method currently does not interpret the axis inversion properties, > since there is no matching flag in the generic linux input device. > > Signed-off-by: Sebastian Reichel Reviewed-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: debugfs: add snapshot to dump requests trbs events
On Mon, Apr 28, 2014 at 10:55:36AM -0500, Felipe Balbi wrote:
> On Mon, Apr 28, 2014 at 04:49:23PM -0400, Zhuang Jin Can wrote:
> > Adds a debugfs file "snapshot" to dump dwc3 requests, trbs and events.
>
> you need to explain what are you trying to provide to our users here.
>
> What "problem" are you trying to solve ?
>
The interface enables users to easily peek into requests, trbs and
events to know the current transfer state of each request.
If an transfer is stuck, user can use the interface to check why it's
stuck (e.g. Is it because a gadget doesn't queued the request? Or it's
queued but it's not primed to the controller? Or It's primed to the
controller but the TRBs and events indicate the transfer never completes?).
User can immediately narrow down the issue without enabling verbose log or
reproduce the issue again. It's helpful when we need to deal with some
hard-to-reproduce bugs or timing sensitive bugs can't be reproduced with
verbose log enabled.
> > As ep0 requests are more complex than others. It's not included in this
> > patch.
>
> For ep0, you could at least print the endpoint phase we are currently
> in and if we have requests in flight or not.
>
Agree. Will add it in [PATCH v2].
> > Signed-off-by: Zhuang Jin Can
> > ---
> > drivers/usb/dwc3/core.h|4 +
> > drivers/usb/dwc3/debugfs.c | 192
> >
> > drivers/usb/dwc3/gadget.h | 41 ++
> > 3 files changed, 237 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> > index 57332e3..9d04ddd 100644
> > --- a/drivers/usb/dwc3/core.h
> > +++ b/drivers/usb/dwc3/core.h
> > @@ -849,6 +849,10 @@ struct dwc3_event_devt {
> > u32 type:4;
> > u32 reserved15_12:4;
> > u32 event_info:9;
> > +
> > +#define DEVT_EVTINFO_SUPERSPEED(1 << 4)
> > +#define DEVT_EVTINFO_HIRD(n) (((n) & (0xf << 5)) >> 5)
> > +
> > u32 reserved31_25:7;
> > } __packed;
> >
> > diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> > index 9ac37fe..078d147 100644
> > --- a/drivers/usb/dwc3/debugfs.c
> > +++ b/drivers/usb/dwc3/debugfs.c
> > @@ -618,6 +618,191 @@ static const struct file_operations
> > dwc3_link_state_fops = {
> > .release= single_release,
> > };
> >
> > +static void dwc3_dump_requests(struct seq_file *s, struct list_head *head,
> > + const char *list_name)
> > +{
> > + struct dwc3_request *req;
> > +
> > + if (list_empty(head)) {
> > + seq_printf(s, "list %s is empty\n", list_name);
> > + return;
> > + }
> > +
> > + seq_printf(s, "list %s:\n", list_name);
> > + list_for_each_entry(req, head, list) {
> > + struct usb_request *request = &req->request;
> > +
> > + seq_printf(s, "usb_request@0x%p: buf@0x%p(dma@0x%pad),
> > len=%d\n",
> > + request, request->buf, &request->dma,
> > + request->length);
> > +
> > + if (req->queued)
> > + seq_printf(s, "\tstatus=%d: actual=%d; start_slot=%u:
> > trb@0x%p(dma@0x%pad)\n",
> > + request->status, request->actual,
> > + req->start_slot, req->trb,
> > + &req->trb_dma);
> > + }
> > +}
> > +
> > +static void dwc3_dump_trbs(struct seq_file *s, struct dwc3_ep *dep)
> > +{
> > + struct dwc3_trb *trb;
> > + int i;
> > +
> > + seq_printf(s, "busy_slot = %u, free_slot = %u\n",
> > + dep->busy_slot & DWC3_TRB_MASK,
> > + dep->free_slot & DWC3_TRB_MASK);
> > +
> > + for (i = 0; i < DWC3_TRB_NUM; i++) {
> > + trb = &dep->trb_pool[i];
> > + if (i == (dep->busy_slot & DWC3_TRB_MASK)) {
>
> I really dislike these Yoda Conditionals. Fix this up.
>
Agree. Will fix it in [PATCH v2].
> > + seq_puts(s, "busy_slot--|\n");
> > + seq_puts(s, " \\\n");
> > + }
> > + if (i == (dep->free_slot & DWC3_TRB_MASK)) {
> > + seq_puts(s, "free_slot--|\n");
> > + seq_puts(s, " \\\n");
> > + }
> > + seq_printf(s, "trb[%02d](dma@0x%pad): %08x(bpl), %08x(bph),
> > %08x(size), %08x(ctrl)\n",
>
> I'm not sure you need to print out the TRB address. bpl, bph, size and
> ctrl are desired though.
>
printing out the TRB DMA address helps user to locate the start TRB of a
request. I admit that we can achive the same purose using the "start_slot"
of the request. I'll remove it in [PATCH v2].
> > + i, &dep->trb_pool_dma + i * sizeof(*trb),
> > + trb->bpl, trb->bph, trb->size, trb->ctrl);
>
> this will be pretty difficult to parse by a human. I would rather see
> you creating one directory per TRB (and also one directory per
> endpoint) which holds the details for that entity, so that it looks
> like:
>
>
Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU
On Mon, Apr 28, 2014 at 06:21:49PM +0100, Joel Fernandes wrote: > On 04/28/2014 12:20 PM, Joel Fernandes wrote: > > On 04/28/2014 11:43 AM, Dave Martin wrote: > >> On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote: > >>> On my DRA7 system, when the kernel is built in THUMB mode, the secondary > >>> CPU > >>> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. > >>> This > >>> seems to be because the CPU is in ARM mode once the ROM hands over > >>> control to > >>> the kernel. Switch to THUMB mode if required once the kernel is control > >>> of > >>> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode > >>> on > >>> entry so this is not required and SMP boot works as is. > >>> > >>> Cc: Santosh Shilimkar > >>> Cc: Russell King > >>> Cc: Nishanth Menon > >>> Cc: Tony Lindgren > >>> Signed-off-by: Joel Fernandes > >>> --- > >>> arch/arm/mach-omap2/omap-headsmp.S |8 ++-- > >>> 1 file changed, 6 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/arch/arm/mach-omap2/omap-headsmp.S > >>> b/arch/arm/mach-omap2/omap-headsmp.S > >>> index 75e9295..1809dce 100644 > >>> --- a/arch/arm/mach-omap2/omap-headsmp.S > >>> +++ b/arch/arm/mach-omap2/omap-headsmp.S > >>> @@ -1,7 +1,7 @@ > >>> /* > >>> * Secondary CPU startup routine source file. > >>> * > >>> - * Copyright (C) 2009 Texas Instruments, Inc. > >>> + * Copyright (C) 2014 Texas Instruments, Inc. > >>> * > >>> * Author: > >>> * Santosh Shilimkar > >>> @@ -28,9 +28,13 @@ > >>> * code. This routine also provides a holding flag into which > >>> * secondary core is held until we're ready for it to initialise. > >>> * The primary core will update this flag using a hardware > >>> -+ * register AuxCoreBoot0. > >>> + * register AuxCoreBoot0. > >>> */ > >>> ENTRY(omap5_secondary_startup) > >> > >> Are you sure this problem is not caused by the missing ENDPROC() for > >> omap5_secondary_startup? > >> > >> You have END() instead (which may have been accidental). > >> > >> Without ENDPROC(), the symbol is not marked as a function and so > >> the Thumb bit won't be set when taking a pointer -- so the kernel > >> is actually telling the firmware to enter in ARM state. > >> > >> > >> Try changing END() to ENDPROC() without this patch, and see if it > >> makes a difference. > >> > >> If it still doesn't work, then the firmware either doesn't support > >> entering in ARM, or is buggy. > > > > Thanks for the suggestion. I'm guessing what you mean is with ENDPROC, > > interworking code uses bx instead of bl to set thumb mode. > > > > But ROM/firmware doesn't have access to symbol table, how would it know > > the type of the symbol to be ARM or THUMB before it branches? > > > Sorry what I meant is, say its of Type function. What tells the firmware > to switch to THUMB? > > What's typically done is a boot address register is written by the > kernel, and the firmware jumps to it after WFE. Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker for x to have the Thumb bit set if the code is Thumb. This means that any reference the linker fixes up for that symbol will have the Thumb bit set appropriately. This applies to any kind of reference, so code in another file that takes the address of the symbol and then passes that address to the firmware should result in the firmware getting an address with the Thumb bit. >From the firmware's point of view it just gets a raw address, but the Thumb bit will now be set. The firmware still needs to handle this correctly when jumping, but from the look of the code this may already work on omap3/4. It would be interesting to know whether it works on omap5. Cheers ---Dave -- 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/5] drivers: w1: omap_hdq: cleanup and bug fixes.
Hi Paul,
On Tuesday 29 April 2014 12:49 AM, Paul Walmsley wrote:
On Wed, 16 Apr 2014, Sourav Poddar wrote:
The patch adds the following to the omap hdq driver.
1. HDQ Device reset call in probe.
2. Enabling '1 wire mode' and checking for presence pulse bit.
3. Proper disabling and enabling of interrupts during read path.
4. Add re-initialization code during SKIP ROM command execution.
5. Miscellaneous cleanup(formatting, return error checks).
Signed-off-by: Sourav Poddar
---
drivers/w1/masters/omap_hdq.c | 85 -
1 file changed, 68 insertions(+), 17 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 9900e8e..0a7bf7f 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
...
@@ -115,6 +116,15 @@ static inline u8 hdq_reg_merge(struct hdq_data *hdq_data,
u32 offset,
return new_val;
}
+static void hdq_disable_interrupt(struct hdq_data *hdq_data, u32 offset,
+ u8 mask)
+{
+ u32 ie;
+
+ ie = readl(hdq_data->hdq_base + offset);
+ writel(ie& mask, hdq_data->hdq_base + offset);
+}
+
Does this function really need to take offset and mask arguments? Won't
they always be constant, and therefore, no need to pass them?
Yes, thats correct, they are always constant and can be used directly
inside the
api. I will fix this in my next version.
- 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 v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 04/29/2014 10:27 AM, George Cherian wrote: > Hi Sebastian, Hi George, > On 4/29/2014 1:36 PM, Sebastian Andrzej Siewior wrote: >> On 04/29/2014 09:58 AM, George Cherian wrote: > This is easily fixed by moving the node at the beggining of the child > list, > so it's probed first. >>> This will give issues on module removal. >>> Since we use device_for_each_child in remove patch, it will try to >>> remove cppi dma controller, while the channel >>> is still in use by musb node. >> Isn't this currently disabled because it blew up in the phy code? > Yes. So how if the dt looks like this No. I remember we talked about this and we decided not to duct tape the bug by moving the nodes around. Instead we wanted to disable the child removal part (one tiny module that can't be removed) until the PHY code does no longer blow up. If the same case is for the DMA driver then it should be fixed, too. The order of the nodes in .dts should not crash the kernel under any circumstances. If a different node order accelerates the probing then fine. But a crash is a no no. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch V2 0/6] dma: edma: Provide granular residue accounting
On Mon, Apr 28, 2014 at 03:47:37PM -0500, Joel Fernandes wrote: > On 04/28/2014 05:49 AM, Thomas Gleixner wrote: > > A simpler version to provide granular residue accounting and readout > > for EDMA. > > > > Delta to V1: > > > > - Removed the double read of the address in PaRAM > > > > - Simplified the stats update in the interrupt callback for > > intermediate transfers > > > > Thanks, > > > > tglx > > > > Thanks for the series. I went over all the patches and it looks great. > Acked-by: Joel Fernandes > > The patches however didn't apply and had some conflicts with my dma > memcpy series and peter's cyclic series so I resolved conflicts and > created a single branch based on Vinod's slave-dma next branch (commit > 406efb1a745c1dc512dc9c3c859e302e7b7f907e) that Vinod can pull. > > I also renamed subject line of patches in Thomas's series to be > "dmaengine: edma" and documented some of the variables used. > > https://github.com/joelagnel/linux-kernel.git (for-vinod branch) > > Vinod, could you pull if it looks OK? The patches look good. But, commit 770f0f3a20188b7e17db2790803b9da925dc0b94 Author: Thomas Gleixner Date: Mon Apr 28 10:49:43 2014 + dmaengine: edma: Make reading the position of active channels work As Joel pointed out, edma_read_position() uses memcpy_fromio() to read the parameter ram. That's not synchronized with the internal update as it does a byte by byte copy. We need to do a 32bit read to get a consistent value. Further reading destination and source is pointless. In DEV_TO_MEM transfers we are only interested in the destination, in MEM_TO_DEV we care about the source. In MEM_TO_MEM it really does not matter which one you read. Simple solution: Remove the pointers, select dest/source via a bool and return the read value. Remove the export of this function while at it. The only potential user is the dmaengine and that's always builtin. Signed-off-by: Thomas Gleixner You s-o-b missing in this one, also ack from Sekhar missing. Do you want to redo this or prefer me to cherry-pick patches adding acks and your s-o-b, since I already fetched your branch Either way is fine with me... -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] arm: omap2: skip device build from platform code for dt.
On Tuesday 29 April 2014 12:09 AM, Felipe Balbi wrote: On Mon, Apr 28, 2014 at 06:28:45PM +, Paul Walmsley wrote: On Wed, 16 Apr 2014, Sourav Poddar wrote: For SOCs with dt enabled, device should be build through device tree. Prevent device build call from platform code, if device tree is enabled. Signed-off-by: Sourav Poddar Isn't OMAP2+ only supporting DT device enumeration now? At least OMAP3 still isn't Dt-only. Yes, for omap3 boards only, I have kept a #ifndef. Else we could have remove this code. -- 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 5/5] arm: hwmod: am437x: Add hwmod data for hdq1w.
Hi Paul, On Tuesday 29 April 2014 03:37 AM, Paul Walmsley wrote: On Wed, 16 Apr 2014, Sourav Poddar wrote: These adds hwmod data for hdq/1w driver. Signed-off-by: Sourav Poddar Is a TRM available yet for AM43x so this patch can be properly reviewed? NO, the TRMS are not yet public. Thanks, Sourav - 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
[PATCHv2] arm: dts: am33xx-clock: Fix ehrpwm tbclk data.
tbclk does not need to be a composite clock, we can simply
use gate clock for this purpose.
Signed-off-by: Sourav Poddar
---
v1->v2:
change compatible string according to mainline.
arch/arm/boot/dts/am33xx-clocks.dtsi | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index 9ccfe50..712edce 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -96,47 +96,29 @@
clock-div = <1>;
};
- ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
#clock-cells = <0>;
- compatible = "ti,composite-no-wait-gate-clock";
+ compatible = "ti,gate-clock";
clocks = <&dpll_per_m2_ck>;
ti,bit-shift = <0>;
reg = <0x0664>;
};
- ehrpwm0_tbclk: ehrpwm0_tbclk {
- #clock-cells = <0>;
- compatible = "ti,composite-clock";
- clocks = <&ehrpwm0_gate_tbclk>;
- };
-
- ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
#clock-cells = <0>;
- compatible = "ti,composite-no-wait-gate-clock";
+ compatible = "ti,gate-clock";
clocks = <&dpll_per_m2_ck>;
ti,bit-shift = <1>;
reg = <0x0664>;
};
- ehrpwm1_tbclk: ehrpwm1_tbclk {
- #clock-cells = <0>;
- compatible = "ti,composite-clock";
- clocks = <&ehrpwm1_gate_tbclk>;
- };
-
- ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
#clock-cells = <0>;
- compatible = "ti,composite-no-wait-gate-clock";
+ compatible = "ti,gate-clock";
clocks = <&dpll_per_m2_ck>;
ti,bit-shift = <2>;
reg = <0x0664>;
};
-
- ehrpwm2_tbclk: ehrpwm2_tbclk {
- #clock-cells = <0>;
- compatible = "ti,composite-clock";
- clocks = <&ehrpwm2_gate_tbclk>;
- };
};
&prcm_clocks {
clk_32768_ck: clk_32768_ck {
--
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
[PATCHv2] arm: dts: am43x-clock: add tbclk data for ehrpwm.
We need "tbclk" clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar
---
v1->v2:
change compatible according to mainline.
arch/arm/boot/dts/am43xx-clocks.dtsi | 48 ++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..401 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = <1>;
clock-div = <1>;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <0>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <1>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <2>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <3>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <4>;
+ reg = <0x0664>;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk@44e10664 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_m2_ck>;
+ ti,bit-shift = <5>;
+ reg = <0x0664>;
+ };
};
&prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, "func_12m_clk", "func_12m_clk"),
DT_CLK(NULL, "vtp_clk_div", "vtp_clk_div"),
DT_CLK(NULL, "usbphy_32khz_clkmux", "usbphy_32khz_clkmux"),
+ DT_CLK("48300200.ehrpwm", "tbclk", "ehrpwm0_tbclk"),
+ DT_CLK("48302200.ehrpwm", "tbclk", "ehrpwm1_tbclk"),
+ DT_CLK("48304200.ehrpwm", "tbclk", "ehrpwm2_tbclk"),
+ DT_CLK("48306200.ehrpwm", "tbclk", "ehrpwm3_tbclk"),
+ DT_CLK("48308200.ehrpwm", "tbclk", "ehrpwm4_tbclk"),
+ DT_CLK("4830a200.ehrpwm", "tbclk", "ehrpwm5_tbclk"),
{ .node_name = NULL },
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
Hi Sebastian,
On 4/29/2014 1:36 PM, Sebastian Andrzej Siewior wrote:
On 04/29/2014 09:58 AM, George Cherian wrote:
This is easily fixed by moving the node at the beggining of the child
list,
so it's probed first.
This will give issues on module removal.
Since we use device_for_each_child in remove patch, it will try to
remove cppi dma controller, while the channel
is still in use by musb node.
Isn't this currently disabled because it blew up in the phy code?
Yes. So how if the dt looks like this
usb {
usb_ctrl_mod {
};
usb0 {
};
usb0_phy {
};
usb1 {
};
usb1_phy {
};
cppi41dma {
};
};
Sebastian
--
-George
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 04/29/2014 09:58 AM, George Cherian wrote: >>> This is easily fixed by moving the node at the beggining of the child >>> list, >>> so it's probed first. > This will give issues on module removal. > Since we use device_for_each_child in remove patch, it will try to > remove cppi dma controller, while the channel > is still in use by musb node. Isn't this currently disabled because it blew up in the phy code? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 4/29/2014 11:49 AM, Yegor Yefremov wrote:
On Thu, Apr 24, 2014 at 11:11 PM, Ezequiel Garcia
wrote:
The DMA controller is needed for the USB controller to be correctly
registered. Therefore, if the DMA node is located at the end an unecessary
probe deferral is produced systematically.
This is easily fixed by moving the node at the beggining of the child list,
so it's probed first.
This will give issues on module removal.
Since we use device_for_each_child in remove patch, it will try to
remove cppi dma controller, while the channel
is still in use by musb node.
Signed-off-by: Ezequiel Garcia
Tested-by: Yegor Yefremov
--
v1->v2:
* Added a comment to prevent a future clean-up based on the memory offset.
arch/arm/boot/dts/am33xx.dtsi | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9770e35..02e1eb6 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -453,6 +453,26 @@
ti,hwmods = "usb_otg_hs";
status = "disabled";
+ /*
+* The probe order matches the child ordering so the
+* dma-controller node must be the first one to prevent
+* spurious probe deferrals.
+*/
+ cppi41dma: dma-controller@47402000 {
+ compatible = "ti,am3359-cppi41";
+ reg = <0x4740 0x1000
+ 0x47402000 0x1000
+ 0x47403000 0x1000
+ 0x47404000 0x4000>;
+ reg-names = "glue", "controller", "scheduler",
"queuemgr";
+ interrupts = <17>;
+ interrupt-names = "glue";
+ #dma-cells = <2>;
+ #dma-channels = <30>;
+ #dma-requests = <256>;
+ status = "disabled";
+ };
+
usb_ctrl_mod: control@44e10620 {
compatible = "ti,am335x-usb-ctrl-module";
reg = <0x44e10620 0x10
@@ -556,20 +576,6 @@
"tx14", "tx15";
};
- cppi41dma: dma-controller@47402000 {
- compatible = "ti,am3359-cppi41";
- reg = <0x4740 0x1000
- 0x47402000 0x1000
- 0x47403000 0x1000
- 0x47404000 0x4000>;
- reg-names = "glue", "controller", "scheduler",
"queuemgr";
- interrupts = <17>;
- interrupt-names = "glue";
- #dma-cells = <2>;
- #dma-channels = <30>;
- #dma-requests = <256>;
- status = "disabled";
- };
};
epwmss0: epwmss@4830 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
--
-George
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] phy: omap-usb2: Add clock names to Documentation binding
Hi Sergei,
On 04/28/2014 08:23 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 04/28/2014 06:01 PM, Roger Quadros wrote:
>
>> Add "wkupclk" and "refclk" information to DT binding information.
>
>> Signed-off-by: Roger Quadros
>> ---
>> Documentation/devicetree/bindings/phy/ti-phy.txt | 7 +++
>> 1 file changed, 7 insertions(+)
>
>> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
>> b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> index 788fb0f..9ce458f 100644
>> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> @@ -32,6 +32,11 @@ Required properties:
>>- reg : Address and length of the register set for the device.
>>- #phy-cells: determine the number of cells that should be given in the
>> phandle while referencing this phy.
>> + - clocks: a list of phandles and clock-specifier pairs, one for each entry
>> in
>> + clock-names.
>
>I thought clock specifier includes phandle. Anyway, this description
> doesn't seem to match your example...
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/clock-bindings.txt#n64
The example was taken from real world where the clock doesn't need specifier.
Examples can always be a subset of supported bindings.
cheers,
-roger
>
>> + - clock-names: should include:
>> + * "wkupclk" - wakeup clock.
>> + * "refclk" - reference clock (optional).
>>
>> Optional properties:
>>- ctrl-module : phandle of the control module used by PHY driver to power
>> on
>> @@ -44,6 +49,8 @@ usb2phy@4a0ad080 {
>> reg = <0x4a0ad080 0x58>;
>> ctrl-module = <&omap_control_usb>;
>> #phy-cells = <0>;
>> +clocks = <&usb_phy_cm_clk32k>, <&usb_otg_ss_refclk960m>;
>> +clock-names = "wkupclk", "refclk";
>> };
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] phy: omap-usb2: Use generic clock names "wkupclk" and "refclk"
+Nishant
Hi,
On 04/28/2014 07:03 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote:
>> As clocks might be named differently on multiple platforms, use a generic
>> name in the driver and allow device tree node to specify the platform
>> specific clock name.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/phy/phy-omap-usb2.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
>> index a2205a8..fb5e515 100644
>> --- a/drivers/phy/phy-omap-usb2.c
>> +++ b/drivers/phy/phy-omap-usb2.c
>> @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device
>> *pdev)
>> if (IS_ERR(phy_provider))
>> return PTR_ERR(phy_provider);
>>
>> -phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
>> +phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
>
> doesn't this patch cause a regression ? I mean, you're changing the
> clock name before fixing DTS. Also, that DTS has been in a major version
> of the kernel, so we need to maintain compatibility with it. How about:
I'm changing the DTS in Patch 4, but I prefer to do it in this patch to prevent
synchronization
issues in -next.
About backward compatibility, I agree with you but at the same time I don't
think anyone using TI
SoCs burns the DTB to ROM and needs backward compatibility. We supply our
BSPs/SDKs with the updated DTBs.
Do you feel strict backward compatibility is worth the effort for TI specific
blocks?
>
> phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
> if (IS_ERR(phy->wkupclk)) {
> dev_err(&pdev->dev, "unable to get wkupclk, trying old name\n");
> phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
> if (IS_ERR(phy->wkupclk)) {
> dev_err(&pdev->dev, "unable to get
> usb_phy_cm_clk32k\n");
> return PTR_ERR(phy->wkupclk);
> } else {
> dev_warn(&pdev->dev, "found usb_phy_cm_clk32k, please
> fix your DTS\n");
> }
> }
>
> a bit ugly, but at least we don't cause any regressions. Likewise for
> other clocks.
>
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
