Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot

2014-02-13 Thread Nishanth Menon
On 02/13/2014 05:05 PM, Tony Lindgren wrote:
> * Nishanth Menon  [140205 06:15]:
>> On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote:
>
> Rather than ti,errata.. specific property, something like
> caps no/disable multiblock read is more readable in my opinion, Otherwise

 Is'nt the better definition to state i have quirk X and allow the
 driver to do the necessary thing/things needed to handle quirk X? in
 this case, there is just one thing to do: broken multi_block_read, in
 the case of other quirks, there might be more than 1 thing to do.. let
 driver figure that out, dts just states the h/w capabilty or in this
 case, the quirk capability.

>>>
>>> But in this case there is only one. disable multi block read is more 
>>> readable
>>> than the errata reference, No strong feelings though.
>>
>> Considering this might set an precedence for other quirk description, 
>> I'd like to leave it as it stands.
> 
> Hmm if this really depends on the hardware version, how about
> just add new compatible flag ti,omap3430-rev-xyz-hsmmc that
> allows the driver to deal with the errata?
> 

yep - that is a very good idea. updated v2 series tested and posted:
http://marc.info/?l=linux-omap&m=139235682727541&w=2
https://patchwork.kernel.org/patch/3650061/
https://patchwork.kernel.org/patch/3650031/


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 2/2] ARM: dts: omap3-ldp: fix mmc configuration

2014-02-13 Thread Nishanth Menon
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block reads, mark it with compatibility for the
same and add pinmux to ensure that all relevant pins are configured
for non-MMC boot mode.

Signed-off-by: Nishanth Menon 
---

Changes since V1:
- fixed commit message as suggested by Balaji.
- update to use new compatible match for the erratum.

V1: https://patchwork.kernel.org/patch/3514881/

 arch/arm/boot/dts/omap3-ldp.dts |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index ddce0d8..0abe986 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -174,8 +174,20 @@
 };
 
 &mmc1 {
+   /* See 35xx errata 2.1.1.128 in SPRZ278F */
+   compatible = "ti,omap3-pre-es3-hsmmc";
vmmc-supply = <&vmmc1>;
bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc1_pins>;
+};
+
+&mmc2 {
+   status="disabled";
+};
+
+&mmc3 {
+   status="disabled";
 };
 
 &omap3_pmx_core {
@@ -209,6 +221,17 @@
0x174 (PIN_OUTPUT | MUX_MODE0)  /* 
hsusb0_stp.hsusb0_stp */
>;
};
+
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.mmc1_clk */
+   OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.mmc1_cmd */
+   OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.mmc1_dat0 */
+   OMAP3_CORE1_IOPAD(0x214A, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.mmc1_dat1 */
+   OMAP3_CORE1_IOPAD(0x214C, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.mmc1_dat2 */
+   OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.mmc1_dat3 */
+   >;
+   };
 };
 
 &usb_otg_hs {
-- 
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 V2 0/2] mmc: omap_hsmmc: fix for pre es3.0 OMAP3

2014-02-13 Thread Nishanth Menon
Originally reported in: https://patchwork.kernel.org/patch/3514851/
https://patchwork.kernel.org/patch/3514881/

ES3.0+ provides MMC controller which is fixed for multi-block reads,
however LDP platform

Looking at the various IP revision register information:
sdp2430: Revision: 1.2, Spec: 0.0, normal interrupt
OMAP3430-ldp: (ES2.1): Revision: 2.6, Spec: 0.0, normal interrupt
SDP3430:(ES3.0) Revision: 2.6, Spec: 0.0, normal interrupt
AM3517-evm: (ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt
AM3517-crane:(ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt
AM37x-evm: (ES1.2) Revision: 2.6, Spec: 0.0, normal interrupt
OMAP3630-beag-xm (ES1.2): Revision: 2.6, Spec: 0.0, normal interrupt
am335x-evm:(ES1.0): Revision: 3.1, Spec: 0.1, normal interrupt
am335x-sk: (ES2.1): Revision: 3.1, Spec: 0.1, normal interrupt
am335x-beaglebone-black:(ES2.0): Revision: 3.1, Spec: 0.1, normal
interrupt
sdp4430: (ES2.2): Revision: 3.1, Spec: 0.1, normal interrupt
OMAP4460-panda-es (ES1.1): Revision: 3.1, Spec: 0.1, normal interrupt
OMAP5uevm:(ES2.0): Revision: 3.3, Spec: 0.2, normal interrupt
dra7-evm (es1.1): Revision: 3.3, Spec: 0.2, normal interrupt

This series has been tested on the following platforms:
 1: BeagleBoard-XM:  Boot PASS: http://slexy.org/raw/s2ObUDfm5N
 2: BeagleBone-Black:  Boot PASS: http://slexy.org/raw/s2xmviGgFf
 3:   dra7:  Boot PASS: http://slexy.org/raw/s2Ad6rxaQk
 4:ldp:  Boot PASS: http://slexy.org/raw/s20kEx9eHg
 5: PandaBoard-ES:  Boot PASS: http://slexy.org/raw/s2gHT1EWKF
 6:sdp2430:  Boot PASS: http://slexy.org/raw/s20dvr8yQA (nfs)
 7:sdp3430:  Boot PASS: http://slexy.org/raw/s2aUEsEemS
 8:sdp4430:  Boot PASS: http://slexy.org/raw/s20nqL8gjz
 9: OMAP5432uEVM:  Boot PASS: http://slexy.org/raw/s20O0QfmZw
TOTAL = 9 boards, Booted Boards = 9, No Boot boards = 0

LDP platform prior to the series reports: http://slexy.org/raw/s20qVg17T0 

Series is based on v3.14-rc2

Nishanth Menon (2):
  mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller
  ARM: dts: omap3-ldp: fix mmc configuration

 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |1 +
 arch/arm/boot/dts/omap3-ldp.dts|   23 +
 drivers/mmc/host/omap_hsmmc.c  |   26 +---
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 1/2] mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller

2014-02-13 Thread Nishanth Menon
When device is booted using devicetree, platforms impacted by Erratum
2.1.1.128 is not detected easily in the mmc driver. This erratum
indicates that the module cannot do multi-block transfers. Platforms
such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by
this.

Provide a new compatible property "ti,omap3-pre-es3-hsmmc" to allow
driver to determine if driver needs to implement quirks associated
with the specific module version (primarily because the IP revision
information is not sufficient for the same).

Signed-off-by: Nishanth Menon 
---
Changes since v1:
- new compatible flag as suggested by Tony which contains
  the relevant controller flag to work around the erratum

V1: https://patchwork.kernel.org/patch/3514851/

 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |1 +
 drivers/mmc/host/omap_hsmmc.c  |   26 +---
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..ce80561 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -10,6 +10,7 @@ Required properties:
 - compatible:
  Should be "ti,omap2-hsmmc", for OMAP2 controllers
  Should be "ti,omap3-hsmmc", for OMAP3 controllers
+ Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
  Should be "ti,omap4-hsmmc", for OMAP4 controllers
 - ti,hwmods: Must be "mmc", n is controller instance starting 1
 
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 575f9cc..390f421 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -192,6 +192,11 @@ struct omap_hsmmc_host {
struct  omap_mmc_platform_data  *pdata;
 };
 
+struct omap_mmc_of_data {
+   u32 reg_offset;
+   u8 controller_flags;
+};
+
 static int omap_hsmmc_card_detect(struct device *dev, int slot)
 {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -1678,18 +1683,29 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
 #endif
 
 #ifdef CONFIG_OF
-static u16 omap4_reg_offset = 0x100;
+static const struct omap_mmc_of_data omap3_pre_es3_mmc_of_data = {
+   /* See 35xx errata 2.1.1.128 in SPRZ278F */
+   .controller_flags = OMAP_HSMMC_BROKEN_MULTIBLOCK_READ,
+};
+
+static const struct omap_mmc_of_data omap4_mmc_of_data = {
+   .reg_offset = 0x100,
+};
 
 static const struct of_device_id omap_mmc_of_match[] = {
{
.compatible = "ti,omap2-hsmmc",
},
{
+   .compatible = "ti,omap3-pre-es3-hsmmc",
+   .data = &omap3_pre_es3_mmc_of_data,
+   },
+   {
.compatible = "ti,omap3-hsmmc",
},
{
.compatible = "ti,omap4-hsmmc",
-   .data = &omap4_reg_offset,
+   .data = &omap4_mmc_of_data,
},
{},
 };
@@ -1759,6 +1775,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
struct pinctrl *pinctrl;
+   const struct omap_mmc_of_data *data;
 
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
if (match) {
@@ -1768,8 +1785,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
return PTR_ERR(pdata);
 
if (match->data) {
-   const u16 *offsetp = match->data;
-   pdata->reg_offset = *offsetp;
+   data = match->data;
+   pdata->reg_offset = data->reg_offset;
+   pdata->controller_flags |= data->controller_flags;
}
}
 
-- 
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] mmc: omap_hsmmc: fix sparse/smatch warning for paranthesis

2014-02-13 Thread Nishanth Menon
commit 6c31b21 (mmc: omap_hsmmc: remove access to SYSCONFIG register)

introduced an smatch(http://smatch.sf.net) warning for the following:

drivers/mmc/host/omap_hsmmc.c:608 omap_hsmmc_context_restore() warn: add
some parenthesis here?
drivers/mmc/host/omap_hsmmc.c:608 omap_hsmmc_context_restore() warn:
maybe use && instead of &

sparse reports:
drivers/mmc/host/omap_hsmmc.c: warning: dubious: !x & y

Fix the same.

Signed-off-by: Nishanth Menon 
---
 drivers/mmc/host/omap_hsmmc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..575f9cc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -605,7 +605,7 @@ static int omap_hsmmc_context_restore(struct 
omap_hsmmc_host *host)
u32 hctl, capa;
unsigned long timeout;
 
-   if (!OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE)
+   if (!(OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE))
return 1;
 
if (host->con == OMAP_HSMMC_READ(host->base, CON) &&
-- 
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: OMAP: clock DT conversion issues with omap36xx

2014-02-13 Thread Christoph Fritz
On Thu, 2014-02-13 at 12:05 +0200, Tomi Valkeinen wrote:
> On 13/02/14 11:03, Tomi Valkeinen wrote:
> > On 12/02/14 15:18, Tomi Valkeinen wrote:
> > 
> >> However, I hacked together the patch below, which "fixes" the issue for
> >> 96m and dss fclk. It sets the clock parents so that the x2 clocks are
> >> skipped, and makes the x2 clock nodes compatible with "unused", making
> >> them effectively disappear. I only verified dss fclk, so Christoph, can
> >> you verify the 96m clock?
> > 
> > Aaand the hack patch I sent is crap... We can't skip the x2 clock path,
> > as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is
> > present on 3630 also.
> > 
> > I think the best and simplest way to fix this is by setting the
> > multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I
> > didn't think of it yesterday.
> > 
> > I have a bunch of other patches needed to get the clocks right, so I'll
> > send a series separately a bit later today.
> 
> I just sent the "OMAP: OMAP3 DSS related clock patches" series to l-o
> and arm lists, which hopefully solves issues discussed in this thread.

Yes, thanks Tomi. I tested your patch series on a83x board. 96m clock
and DSS-clocks are fine now. If you want, you can add my:

 Tested-by: Christoph Fritz 

to your series "OMAP: OMAP3 DSS related clock patches".

The only issue left on current mainline for a83x board is that twl4030
(tps65920) doesn't set VIO as on next-20140120.

 Thanks
  -- Christoph

--
To unsubscribe from this list: send the line "unsubscribe 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: omap3 clocks: simplify ssi aliases

2014-02-13 Thread Sebastian Reichel
On Thu, Feb 13, 2014 at 02:49:14PM -0800, Tony Lindgren wrote:
> * Sebastian Reichel  [140121 06:39]:
> > update aliases for the ssi clocks ssi_ssr_fck, ssi_sst_fck and ssi_ick
> > to make them consistent for omap34xx and omap36xx. This makes it
> > possible to reference the clocks from generic omap3 dts files.
> 
> Is this needed as a fix for v3.14-rc? If so, please let me know
> and ack if you want me to take it.

The SSI driver will not arrive before 3.15 and 3.14 dts files do not
contain any SSI nodes.

Thus it should be enough to queue it for 3.15 if it goes via the
same tree as the SSI dts patches.

-- Sebastian


signature.asc
Description: Digital signature


Re: [PATCH] [RESEND] ARM/dts: hdmi-codec: panda/es dt entries

2014-02-13 Thread Tony Lindgren
* Paolo Pisati  [140213 08:00]:
> Signed-off-by: Paolo Pisati 

Missing description? Please also Cc Peter Ujfalusi on this
and let me know if this is needed as a fix for the -rc cycle.

Regards,

Tony

> ---
>  arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
>  arch/arm/boot/dts/omap4-panda-es.dts  |3 ++-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 88c6a05..f4aeaa1 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -36,9 +36,15 @@
>   };
>   };
>  
> + hdmi_audio: hdmi_audio@0 {
> + compatible = "linux,hdmi-audio";
> + status = "okay";
> + };
> +
>   sound: sound {
>   compatible = "ti,abe-twl6040";
>   ti,model = "PandaBoard";
> + ti,audio-codec = <&hdmi_audio>;
>  
>   ti,mclk-freq = <3840>;
>  
> @@ -57,7 +63,8 @@
>   "HSMIC", "Headset Mic",
>   "Headset Mic", "Headset Mic Bias",
>   "AFML", "Line In",
> - "AFMR", "Line In";
> + "AFMR", "Line In",
> + "HDMI Out", "TX";
>   };
>  
>   /* HS USB Port 1 Power */
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 816d1c9..70152d6 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -23,7 +23,8 @@
>   "Line Out", "AUXL",
>   "Line Out", "AUXR",
>   "AFML", "Line In",
> - "AFMR", "Line In";
> + "AFMR", "Line In",
> + "HDMI Out", "TX";
>  };
>  
>  /* PandaboardES has external pullups on SCL & SDA */
> -- 
> 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 0/4] ARM: dts: Fixes for Overo/Tobi against 3.14-rc2

2014-02-13 Thread Tony Lindgren
* Florian Vaussard  [140213 02:28]:
> OMAP36xx-based Overo (Storm and alike) are now failing to boot with 3.14-rc2 
> [1].
> This series fixes this, by moving model-agnostic DT into a common dtsi file,
> and creating model-specific DT files:
> 
> - omap3-overo-tobi.dts -> older OMAP35xx Overo
> - omap3-overo-storm-tobi.dts -> newer OMAP36xx/AM37xx/DM37xx Overo
> 
> People will have to use the right Overo / expansion board combination.
> 
> (Patch 2 in an unrelated fix that was waiting in my queue.)
> 
> omap3-overo-tobi.dts tested with Overo Sand (OMAP3503) and 
> omap3-overo-storm-tobi.dts
> tested with Overo EarthStorm (AM3703). Both boot. With the Overo Sand, I 
> cannot
> mount the ext3 rootfs, but this seems unrelated to the current topic, maybe
> a missing errata.

Applying patches 1 to 3 into omap-for-v3.14/fixes thanks, the last
one still seems to have discussion going.

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: OMAP2+: Remove legacy macros for zoom platforms

2014-02-13 Thread Tony Lindgren
* Paul Bolle  [140212 01:48]:
> Commit 97411608fd5f ("ARM: OMAP2+: Remove legacy support for zoom
> platforms") removed the Kconfig symbols MACH_OMAP_ZOOM2 and
> MACH_OMAP_ZOOM3. Remove the last usage of the related macros too.
> 
> Signed-off-by: Paul Bolle 
> ---
> Untested, but should have zero impact.

Thanks applying into omap-for-v3.14/fixes.

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: OMAP2+: Remove MACH_NOKIA_N800

2014-02-13 Thread Tony Lindgren
* Aaro Koskinen  [140209 11:53]:
> Hi,
> 
> On Sun, Feb 09, 2014 at 04:01:28PM +0100, Paul Bolle wrote:
> > The last caller of machine_is_nokia_n800() was removed in commit
> > 5a87cde490e1 ("ARM: OMAP2+: Remove legacy booting support for n8x0").
> > That means that the Kconfig symbol MACH_NOKIA_N800 is now unused. It can
> > safely be removed.
> > 
> > Signed-off-by: Paul Bolle 
> 
> Acked-by: Aaro Koskinen 

Thanks applying into omap-for-v3.14/fixes.

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: dtsi: am335x-bone-common, usb0 is peripheral only

2014-02-13 Thread Tony Lindgren
* Markus Pargmann  [140213 15:16]:
> Hi,
> 
> On Thu, Feb 13, 2014 at 02:54:38PM -0800, Tony Lindgren wrote:
> > * Markus Pargmann  [140111 06:03]:
> > > The PMIC is using usb0 vbus line as power source. It is also connected
> > > to the am335x processor as vbus sense. But there is no possibility to
> > > pullup usb0 vbus to operate as host. This patch fixes the dr_mode of usb0.
> > 
> > That's the MUSB? AFAIK it's not possible to operate MUSB in peripheral
> > only mode because the hardware does what it wants based on the ID
> > pin state.
> 
> Yes that's MUSB. The am335x reference manual describes that it is
> possible to force peripheral/host mode by setting bit 7 (IDDIG_MUX) in
> register USBnMODE to 1. Then it uses the bit written in bit 8 (IDDIG) of
> register USBnMODE to set host/peripheral mode.

OK
 
> I am not sure if the driver supports it yet but I think the DTS should
> contain the correct mode nevertheless, especially to avoid starting the
> otg loops in the musb driver.

Well there's one more thing to consider.. I think in the OTG role change
case the VBUS is still driven externally from the original host, so the
lack of VBUS does not always mean that host mode should be disabled.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] ARM: dts: N9/N950: fix boot hang with 3.14-rc1

2014-02-13 Thread Tony Lindgren
* Nishanth Menon  [140211 12:13]:
> On 02/09/2014 06:12 AM, Aaro Koskinen wrote:
> > N9/N950 does not boot anymore with 3.14-rc1, because SoC compatible
> > property is missing. Fix that.
> > 
> > Signed-off-by: Aaro Koskinen 
> 
> Reviewed-by: Nishanth Menon 

Applying both into omap-for-v3.14/fixes thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: OMAP1: nokia770: enable tahvo-usb

2014-02-13 Thread Tony Lindgren
* Aaro Koskinen  [140208 05:52]:
> Add platform data for tahvo-usb. This is the last missing piece to get
> Tahvo USB working with 3.14.

Applying into omap-for-v3.14/fixes thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 4/4] ARM: OMAP2+: AM43x: Use gptimer as clocksource

2014-02-13 Thread Tony Lindgren
* Lokesh Vutla  [140207 02:24]:
> From: Rajendra Nayak 
> 
> The SyncTimer in AM43x is clocked using the following two sources:
> 1) An inaccuarte 32k clock (CLK_32KHZ) derived from PER DPLL, causing system
>time to go slowly (~10% deviation).
> 2) external 32KHz RTC clock, which may not always be available on board like
>in the case of ePOS EVM
> 
> Use gptimer as clocksource instead, as is done in the case of AM335x
> (which does not have a SyncTimer). With this, system time keeping works
> accurately.

Hmm doesn't this also mean that PM for any deeper idle states won't
work properly?

Regards,

Tony
 
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/mach-omap2/board-generic.c |2 +-
>  arch/arm/mach-omap2/timer.c |3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c 
> b/arch/arm/mach-omap2/board-generic.c
> index 8e3daa1..5679464a 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -229,7 +229,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device 
> Tree)")
>   .init_late  = am43xx_init_late,
>   .init_irq   = omap_gic_of_init,
>   .init_machine   = omap_generic_init,
> - .init_time  = omap3_sync32k_timer_init,
> + .init_time  = omap3_gptimer_timer_init,
>   .dt_compat  = am43_boards_compat,
>  MACHINE_END
>  #endif
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 74044aa..b62de9f 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -604,7 +604,8 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", 
> "ti,timer-secure",
>   2, "timer_sys_ck", NULL);
>  #endif /* CONFIG_ARCH_OMAP3 */
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
> + defined(CONFIG_SOC_AM43XX)
>  OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
>  1, "timer_sys_ck", "ti,timer-alwon");
>  #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] ARM: OMAP3+: DPLL: stop reparenting to same parent if already done

2014-02-13 Thread Tony Lindgren
* Nishanth Menon  [140205 01:06]:
> omap3_noncore_dpll_set_rate forces a reparent to the same clk_ref
> for every call that takes place. This is an can be done only if a change
> is detected.
> 
> Signed-off-by: Nishanth Menon 

Would like to see acks on this too before applying.

Tony

> ---
>  arch/arm/mach-omap2/dpll3xxx.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
> index 3185ced..d9bcbf7 100644
> --- a/arch/arm/mach-omap2/dpll3xxx.c
> +++ b/arch/arm/mach-omap2/dpll3xxx.c
> @@ -525,7 +525,7 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>   * stuff is inherited for free
>   */
>  
> - if (!ret)
> + if (!ret && clk_get_parent(hw->clk) != new_parent)
>   __clk_reparent(hw->clk, new_parent);
>  
>   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


Re: [PATCH] arm: dtsi: am335x-bone-common, usb0 is peripheral only

2014-02-13 Thread Markus Pargmann
Hi,

On Thu, Feb 13, 2014 at 02:54:38PM -0800, Tony Lindgren wrote:
> * Markus Pargmann  [140111 06:03]:
> > The PMIC is using usb0 vbus line as power source. It is also connected
> > to the am335x processor as vbus sense. But there is no possibility to
> > pullup usb0 vbus to operate as host. This patch fixes the dr_mode of usb0.
> 
> That's the MUSB? AFAIK it's not possible to operate MUSB in peripheral
> only mode because the hardware does what it wants based on the ID
> pin state.

Yes that's MUSB. The am335x reference manual describes that it is
possible to force peripheral/host mode by setting bit 7 (IDDIG_MUX) in
register USBnMODE to 1. Then it uses the bit written in bit 8 (IDDIG) of
register USBnMODE to set host/peripheral mode.

I am not sure if the driver supports it yet but I think the DTS should
contain the correct mode nevertheless, especially to avoid starting the
otg loops in the musb driver.

Regards,

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

2014-02-13 Thread Tony Lindgren
* Tomi Valkeinen  [140130 03:19]:
> If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
> clk_set_rate() on the clock "skips" the x2 multiplier as there are no
> set_rate and round_rate functions defined for the clkoutx2.
> 
> This results in getting double the requested clock rates, breaking the
> display on omap3430 based devices. This got broken when
> d0f58bd3bba3877fb1af4664c4e33273d36f00e4 and related patches were merged
> for v3.14, as omapdss driver now relies more on the clk-framework and
> CLK_SET_RATE_PARENT.
> 
> This patch implements set_rate and round_rate for clkoutx2.
> 
> Tested on OMAP3430, OMAP3630, OMAP4460.
> 
> Signed-off-by: Tomi Valkeinen 

Would like to see acks from Paul and Tero on this too before applying.

Tony

> ---
>  arch/arm/mach-omap2/cclock3xxx_data.c |  2 +
>  arch/arm/mach-omap2/dpll3xxx.c| 92 
> +--
>  include/linux/clk/ti.h|  4 ++
>  3 files changed, 83 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
> b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 3b05aea56d1f..11ed9152e665 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
>   .enable = &omap2_dflt_clk_enable,
>   .disable= &omap2_dflt_clk_disable,
>   .is_enabled = &omap2_dflt_clk_is_enabled,
> + .set_rate   = &omap3_clkoutx2_set_rate,
>   .recalc_rate= &omap3_clkoutx2_recalc,
> + .round_rate = &omap3_clkoutx2_round_rate,
>  };
>  
>  static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
> index 3185ced807c9..3c418ea54bbe 100644
> --- a/arch/arm/mach-omap2/dpll3xxx.c
> +++ b/arch/arm/mach-omap2/dpll3xxx.c
> @@ -623,6 +623,32 @@ void omap3_dpll_deny_idle(struct clk_hw_omap *clk)
>  
>  /* Clock control for DPLL outputs */
>  
> +/* Find the parent DPLL for the given clkoutx2 clock */
> +static struct clk_hw_omap *omap3_find_clkoutx2_dpll(struct clk_hw *hw)
> +{
> + struct clk_hw_omap *pclk = NULL;
> + struct clk *parent;
> +
> + /* Walk up the parents of clk, looking for a DPLL */
> + do {
> + do {
> + parent = __clk_get_parent(hw->clk);
> + hw = __clk_get_hw(parent);
> + } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
> + if (!hw)
> + break;
> + pclk = to_clk_hw_omap(hw);
> + } while (pclk && !pclk->dpll_data);
> +
> + /* clk does not have a DPLL as a parent?  error in the clock data */
> + if (!pclk) {
> + WARN_ON(1);
> + return NULL;
> + }
> +
> + return pclk;
> +}
> +
>  /**
>   * omap3_clkoutx2_recalc - recalculate DPLL X2 output virtual clock rate
>   * @clk: DPLL output struct clk
> @@ -637,27 +663,14 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
>   unsigned long rate;
>   u32 v;
>   struct clk_hw_omap *pclk = NULL;
> - struct clk *parent;
>  
>   if (!parent_rate)
>   return 0;
>  
> - /* Walk up the parents of clk, looking for a DPLL */
> - do {
> - do {
> - parent = __clk_get_parent(hw->clk);
> - hw = __clk_get_hw(parent);
> - } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
> - if (!hw)
> - break;
> - pclk = to_clk_hw_omap(hw);
> - } while (pclk && !pclk->dpll_data);
> + pclk = omap3_find_clkoutx2_dpll(hw);
>  
> - /* clk does not have a DPLL as a parent?  error in the clock data */
> - if (!pclk) {
> - WARN_ON(1);
> + if (!pclk)
>   return 0;
> - }
>  
>   dd = pclk->dpll_data;
>  
> @@ -672,6 +685,55 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
>   return rate;
>  }
>  
> +int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + return 0;
> +}
> +
> +long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> + const struct dpll_data *dd;
> + u32 v;
> + struct clk_hw_omap *pclk = NULL;
> +
> + if (!*prate)
> + return 0;
> +
> + pclk = omap3_find_clkoutx2_dpll(hw);
> +
> + if (!pclk)
> + return 0;
> +
> + dd = pclk->dpll_data;
> +
> + /* TYPE J does not have a clkoutx2 */
> + if (dd->flags & DPLL_J_TYPE) {
> + *prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
> + return *prate;
> + }
> +
> + WARN_ON(!dd->enable_mask);
> +
> + v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
> + v >>= __ffs(dd->enable_mask);
> +
> + /* If in bypass, the rate is fixed to the bypass rat

Re: [PATCH] ARM: OMAP2+: gpmc: fix: DT NAND child nodes not probed when MTD_NAND is built as module

2014-02-13 Thread Tony Lindgren
* Pekon Gupta  [140127 22:15]:
> Fixes: commit bc6b1e7b86f5d8e4a6fc1c0189e64bba4077efe0
>ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
> 
> OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and
> register them platform_device for NAND driver to probe later. However this 
> does
> not happen if generic MTD_NAND framework is built as module 
> (CONFIG_MTD_NAND=m).
> 
> Therefore, when MTD/NAND and MTD/NAND/OMAP2 modules are loaded, they are 
> unable
> to find any matching platform_device and remain un-binded. This causes on 
> board
> NAND flash to remain un-detected.
> 
> This patch causes GPMC controller to parse DT nodes when
> CONFIG_MTD_NAND=y || CONFIG_MTD_NAND=m

Applying into omap-for-v3.14/fixes for this and the onenand patch.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/9] ARM: dts: omap3-gta04: Fix mmc1 properties.

2014-02-13 Thread Tony Lindgren
* Marek Belisko  [140125 13:31]:
> Does not have an aux supply, and must be non-removable.
> 
> Otherwise it is removed during suspend and filesystem gets confused.
> 
> Signed-off-by: NeilBrown 
> ---
>  arch/arm/boot/dts/omap3-gta04.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
> b/arch/arm/boot/dts/omap3-gta04.dts
> index e315675..6011151 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dts
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -149,8 +149,8 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <&mmc1_pins>;
>   vmmc-supply = <&vmmc1>;
> - vmmc_aux-supply = <&vsim>;
>   bus-width = <4>;
> + ti,non-removable;
>  };
>  
>  &mmc2 {

Taking this too into omap-for-v3.14/fixes.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/9] ARM: dts: omap3-gta04: Fix 'aux' gpio key flags.

2014-02-13 Thread Tony Lindgren
* Marek Belisko  [140125 13:31]:
> From: NeilBrown 
> 
> It should be ACTIVE_HIGH.
> 
> Signed-off-by: NeilBrown 
> ---
>  arch/arm/boot/dts/omap3-gta04.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
> b/arch/arm/boot/dts/omap3-gta04.dts
> index b9b55c9..9d37184 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dts
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -32,7 +32,7 @@
>   aux-button {
>   label = "aux";
>   linux,code = <169>;
> - gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
> + gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
>   gpio-key,wakeup;
>   };
>   };

Picking this one into omap-for-v3.14/fixes thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot

2014-02-13 Thread Tony Lindgren
* Nishanth Menon  [140205 06:15]:
> On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote:
> >>>
> >>> Rather than ti,errata.. specific property, something like
> >>> caps no/disable multiblock read is more readable in my opinion, Otherwise
> >>
> >> Is'nt the better definition to state i have quirk X and allow the
> >> driver to do the necessary thing/things needed to handle quirk X? in
> >> this case, there is just one thing to do: broken multi_block_read, in
> >> the case of other quirks, there might be more than 1 thing to do.. let
> >> driver figure that out, dts just states the h/w capabilty or in this
> >> case, the quirk capability.
> >>
> >
> > But in this case there is only one. disable multi block read is more 
> > readable
> > than the errata reference, No strong feelings though.
> 
> Considering this might set an precedence for other quirk description, 
> I'd like to leave it as it stands.

Hmm if this really depends on the hardware version, how about
just add new compatible flag ti,omap3430-rev-xyz-hsmmc that
allows the driver to deal with the errata?

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 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round

2014-02-13 Thread Tony Lindgren
* Tomi Valkeinen  [140116 23:47]:
> 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 

Paul & Tero, please ack if you want me to queue this.

Tony

> ---
>  arch/arm/mach-omap2/clkt_dpll.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
> index 1f1708ef77bb..1b4e68dfb713 100644
> --- a/arch/arm/mach-omap2/clkt_dpll.c
> +++ b/arch/arm/mach-omap2/clkt_dpll.c
> @@ -298,6 +298,7 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned 
> long target_rate,
>   struct dpll_data *dd;
>   unsigned long ref_rate;
>   const char *clk_name;
> + unsigned long diff, closest_diff = ~0;
>  
>   if (!clk || !clk->dpll_data)
>   return ~0;
> @@ -345,20 +346,26 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned 
> long target_rate,
>   pr_debug("clock: %s: m = %d: n = %d: new_rate = %lu\n",
>clk_name, m, n, new_rate);
>  
> - if (target_rate == new_rate) {
> + diff = max(target_rate, new_rate) - min(target_rate, new_rate);
> +
> + if (diff < closest_diff) {
> + closest_diff = diff;
> +
>   dd->last_rounded_m = m;
>   dd->last_rounded_n = n;
> - dd->last_rounded_rate = target_rate;
> - break;
> + dd->last_rounded_rate = new_rate;
> +
> + if (diff == 0)
> + break;
>   }
>   }
>  
> - if (target_rate != new_rate) {
> + if (closest_diff == ~0) {
>   pr_debug("clock: %s: cannot round to rate %lu\n",
>clk_name, target_rate);
>   return ~0;
>   }
>  
> - return target_rate;
> + return dd->last_rounded_rate;
>  }
>  
> -- 
> 1.8.3.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: OMAP2+: add missing ARCH_HAS_OPP

2014-02-13 Thread Tony Lindgren
* Nishanth Menon  [140129 05:29]:
> Hi Tony,
> On 01/15/2014 02:00 PM, Nishanth Menon wrote:
> > OMAP5, DRA7, AM43xx all have OPPs. So select the same to allow SoC
> > only configuration boot to work with OPP.
> > 
> > Reported-by: Nikhil Devshatwar 
> > Signed-off-by: Nishanth Menon 
> > ---
> > 
> > For DRA7, depends on: https://patchwork.kernel.org/patch/3465411/
> 
> Considering that dependent patch is now on linus master,
> a gentle ping -> The patch does apply on latest linus master commit
> 0e47c969c65e213421450c31043353ebe3c67e0c

Thanks applying into omap-for-v3.14/fixes.

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: dtsi: am335x-bone-common, usb0 is peripheral only

2014-02-13 Thread Tony Lindgren
* Markus Pargmann  [140111 06:03]:
> The PMIC is using usb0 vbus line as power source. It is also connected
> to the am335x processor as vbus sense. But there is no possibility to
> pullup usb0 vbus to operate as host. This patch fixes the dr_mode of usb0.

That's the MUSB? AFAIK it's not possible to operate MUSB in peripheral
only mode because the hardware does what it wants based on the ID
pin state.

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: omap1: fix build when !CONFIG_OMAP_32K_TIMER

2014-02-13 Thread Tony Lindgren
* Felipe Balbi  [140113 10:06]:
> If CONFIG_OMAP_32K_TIMER isn't enabled, we will
> try to use enable_dyn_sleep which wasn't defined
> anywhere.
> 
> In order to fix the problem, we always define
> enable_dyn_sleep as 0 when !CONFIG_OMAP_32K_TIMER.
> 
> Signed-off-by: Felipe Balbi 

Thanks applying into omap-for-v3.14/fixes.

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: dts: omap3 clocks: simplify ssi aliases

2014-02-13 Thread Tony Lindgren
* Sebastian Reichel  [140121 06:39]:
> update aliases for the ssi clocks ssi_ssr_fck, ssi_sst_fck and ssi_ick
> to make them consistent for omap34xx and omap36xx. This makes it
> possible to reference the clocks from generic omap3 dts files.

Is this needed as a fix for v3.14-rc? If so, please let me know
and ack if you want me to take it.

Tony
 
> Signed-off-by: Sebastian Reichel 
> ---
>  arch/arm/boot/dts/omap3430es1-clocks.dtsi  | 10 +-
>  arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi | 10 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi 
> b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> index 02f6c7f..6f31954 100644
> --- a/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
> @@ -82,16 +82,16 @@
>   ti,dividers = <0>, <1>, <2>, <3>, <4>, <0>, <6>, <0>, <8>;
>   };
>  
> - ssi_ssr_fck_3430es1: ssi_ssr_fck_3430es1 {
> + ssi_ssr_fck: ssi_ssr_fck_3430es1 {
>   #clock-cells = <0>;
>   compatible = "ti,composite-clock";
>   clocks = <&ssi_ssr_gate_fck_3430es1>, 
> <&ssi_ssr_div_fck_3430es1>;
>   };
>  
> - ssi_sst_fck_3430es1: ssi_sst_fck_3430es1 {
> + ssi_sst_fck: ssi_sst_fck_3430es1 {
>   #clock-cells = <0>;
>   compatible = "fixed-factor-clock";
> - clocks = <&ssi_ssr_fck_3430es1>;
> + clocks = <&ssi_ssr_fck>;
>   clock-mult = <1>;
>   clock-div = <2>;
>   };
> @@ -120,7 +120,7 @@
>   clock-div = <1>;
>   };
>  
> - ssi_ick_3430es1: ssi_ick_3430es1 {
> + ssi_ick: ssi_ick_3430es1 {
>   #clock-cells = <0>;
>   compatible = "ti,omap3-no-wait-interface-clock";
>   clocks = <&ssi_l4_ick>;
> @@ -203,6 +203,6 @@
><&i2c1_ick>, <&uart2_ick>, <&uart1_ick>, <&gpt11_ick>,
><&gpt10_ick>, <&mcbsp5_ick>, <&mcbsp1_ick>,
><&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>,
> -  <&fshostusb_fck>, <&fac_ick>, <&ssi_ick_3430es1>;
> +  <&fshostusb_fck>, <&fac_ick>, <&ssi_ick>;
>   };
>  };
> diff --git a/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi 
> b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
> index 8ed475d..877318c 100644
> --- a/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
> @@ -25,16 +25,16 @@
>   ti,dividers = <0>, <1>, <2>, <3>, <4>, <0>, <6>, <0>, <8>;
>   };
>  
> - ssi_ssr_fck_3430es2: ssi_ssr_fck_3430es2 {
> + ssi_ssr_fck: ssi_ssr_fck_3430es2 {
>   #clock-cells = <0>;
>   compatible = "ti,composite-clock";
>   clocks = <&ssi_ssr_gate_fck_3430es2>, 
> <&ssi_ssr_div_fck_3430es2>;
>   };
>  
> - ssi_sst_fck_3430es2: ssi_sst_fck_3430es2 {
> + ssi_sst_fck: ssi_sst_fck_3430es2 {
>   #clock-cells = <0>;
>   compatible = "fixed-factor-clock";
> - clocks = <&ssi_ssr_fck_3430es2>;
> + clocks = <&ssi_ssr_fck>;
>   clock-mult = <1>;
>   clock-div = <2>;
>   };
> @@ -55,7 +55,7 @@
>   clock-div = <1>;
>   };
>  
> - ssi_ick_3430es2: ssi_ick_3430es2 {
> + ssi_ick: ssi_ick_3430es2 {
>   #clock-cells = <0>;
>   compatible = "ti,omap3-ssi-interface-clock";
>   clocks = <&ssi_l4_ick>;
> @@ -193,6 +193,6 @@
><&i2c1_ick>, <&uart2_ick>, <&uart1_ick>, <&gpt11_ick>,
><&gpt10_ick>, <&mcbsp5_ick>, <&mcbsp1_ick>,
><&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>,
> -  <&ssi_ick_3430es2>;
> +  <&ssi_ick>;
>   };
>  };
> -- 
> 1.8.5.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/2] ARM: DTS: am335x-evmsk: Audio and MMC1 fix (for 3.13?)

2014-02-13 Thread Tony Lindgren
* Peter Ujfalusi  [140107 00:16]:
> Hi Benoit,
> 
> On 12/23/2013 11:28 AM, Peter Ujfalusi wrote:
> > Hi,
> > 
> > The audio frequency has been incorrectly set in the DTS file which results
> > incorrect playback frequency on EVM-SK.
> > 
> > The SD card can not be used without the second patch on 3.13-rc5.
> 
> Can you take a look at these and if it is possible send it for 3.13?

Applying both into omap-for-v3.14/fixes thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: dts: omap3-gta04: Add EOC irq gpio line handling.

2014-02-13 Thread Tony Lindgren
* Belisko Marek  [140120 12:27]:
> Ping? Benoit can you please merge this trivial update. Thanks.

Applying into omap-for-v3.14/fixes thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Issues with GPIO and wake from sleep

2014-02-13 Thread Tony Lindgren
* Marc Murphy  [140205 15:20]:
> I have now stepped through most of the system as it goes into the sleep 
> state.  It will transition into omap34xx_cpu_suspend and eventually work 
> itself into an endless loop.
> 
> I have then taken a step back to see the config of the system and all kernel 
> options seem to be correct with power management. 
> 
> I then looked at the boot line, I am running tftp which should be a problem 
> for the suspend to ram, and there is an option of nohlt :
> setenv bootargs console=${console},115200n8 ${mem_size} mpurate=${mpurate} 
> ${video_mode} ${extra_options} root=${nfsroot} rootfstype=nfs ip=dhcp nohlt rw
> 
> I was informed I needed to do this quite some time ago when I was having 
> issue with the system booting.  Upon reading the kernel-paramters doc I see 
> that the description is what I am experiencing;
>   nohlt   [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
>   wfi(ARM) instruction doesn't work correctly and not to
>   use it. This is also useful when using JTAG debugger.
> 
> OK so WFI doesn't work correctly, I have no WFI operating.  If I remove the 
> nohlt from the boot line the system freezes;
> [2.833587] voltdm_scale: No voltage scale API registered for vdd_core
> [2.840454] PM: no software I/O chain control; some wakeups may be lost
> [2.856536] davinci_emac davinci_emac.0: using random MAC addr: 
> 86:2d:4d:a4:87:3e

It seems that this is a 3517 based issue, maybe the davinci_emac driver
won't work properly with runtime PM?

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 6/6] arm: dts: am335x beagle bone use processor macids

2014-02-13 Thread Uwe Kleine-König
Hello,

On Wed, Dec 18, 2013 at 05:47:22PM +0100, Markus Pargmann wrote:
> Use macids stored in the am335x chip.
> 
> Signed-off-by: Markus Pargmann 
> ---
>  arch/arm/boot/dts/am335x-bone.dts  | 8 
>  arch/arm/boot/dts/am335x-boneblack.dts | 8 
>  2 files changed, 16 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone.dts 
> b/arch/arm/boot/dts/am335x-bone.dts
> index 94ee427..9b65a62 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -10,6 +10,14 @@
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
>  
> +&cpsw_emac0 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 0>;
> +};
> +
> +&cpsw_emac1 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 1>;
> +};
with the mac-address property overwriting the addresses found in the
mac-address-ctrl block as I suggested in reply to the respective patch,
I'd add this property not per machine but directly in am33xx.dtsi.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/6] net: cpsw: Add control-module macid driver

2014-02-13 Thread Uwe Kleine-König
On Wed, Dec 18, 2013 at 05:47:19PM +0100, Markus Pargmann wrote:
> This driver extracts the hardware macid from the control module of
> am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw
> to get the macid from within the processor.
> 
> This driver is not used, unless it is defined in DT and referenced by a
> cpsw slave with a phandle.
> 
> Signed-off-by: Markus Pargmann 
> ---
>  .../devicetree/bindings/net/cpsw-ctrl-macid.txt|  31 +
>  drivers/net/ethernet/ti/Kconfig|   8 ++
>  drivers/net/ethernet/ti/Makefile   |   1 +
>  drivers/net/ethernet/ti/cpsw-ctrl-macid.c  | 138 
> +
>  4 files changed, 178 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
>  create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c
> 
> diff --git a/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt 
> b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
> new file mode 100644
> index 000..abff2af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
> @@ -0,0 +1,31 @@
> +TI CPSW ctrl macid Devicetree bindings
> +--
> +
> +Required properties:
> + - compatible: Should be "ti,am3352-cpsw-ctrl-macid"
> + - reg   : physical base address and size of the cpsw
> +   registers map
> + - reg-names : names of the register map given in "reg" node
> + - #ti,cpsw-ctrl-macid   : Should be <1>
#ti,mac-address-ctrl-cells?

> +
> +When used from cpsw, "ti,mac-address-ctrl" should be a phandle to this device
> +node with one argument, 0 or 1 to select the macid 0 or 1.
> +
> +Examples:
> +
> + cpsw_ctrl_macid: cpsw-ctrl-macid@44e10630 {
> + compatible = "ti,am3352-cpsw-ctrl-macid";
> + #ti,mac-address-ctrl-cells = <1>;
> + reg = <0x44e10630 0x16>;
s/0x16/0x10/

> + reg-names = "ctrl-macid";
> + };
> +
> +Used in cpsw slave nodes like this:
> +
> + cpsw_emac0: slave@4a100200 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 0>;
> + };
> +
> + cpsw_emac1: slave@4a100300 {
> + ti,mac-address-ctrl = <&cpsw_ctrl_macid 1>;
> + };
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index 53150c2..24819ef 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -56,12 +56,20 @@ config TI_CPSW_PHY_SEL
> This driver supports configuring of the phy mode connected to
> the CPSW.
>  
> +config TI_CPSW_CTRL_MACID
> + boolean "TI CPSW internal MACID support"
> + depends on TI_CPSW
> + ---help---
> +   This driver supports reading the hardcoded MACID from am33xx
> +   processors control module.
> +
Would it be nicer to put this after the TI_CPSW definition. (Think
$(make config).)

>  config TI_CPSW
>   tristate "TI CPSW Switch Support"
>   depends on ARM && (ARCH_DAVINCI || SOC_AM33XX)
>   select TI_DAVINCI_CPDMA
>   select TI_DAVINCI_MDIO
>   select TI_CPSW_PHY_SEL
> + select TI_CPSW_CTRL_MACID
If TI_CPSW selects TI_CPSW_CTRL_MACID the latter doesn't need to depend
on the former. So this optin is user visible but never
user-(de)selectable. I'd say drop the Kconfig symbol and just add
cpsw-ctrl-macid.o to ti_cpsw-y in the Makefile (or really make it
optional).

>   ---help---
> This driver supports TI's CPSW Ethernet Switch.
>  
> diff --git a/drivers/net/ethernet/ti/Makefile 
> b/drivers/net/ethernet/ti/Makefile
> index 9cfaab8..5a31c2b 100644
> --- a/drivers/net/ethernet/ti/Makefile
> +++ b/drivers/net/ethernet/ti/Makefile
> @@ -8,5 +8,6 @@ obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
>  obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
>  obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
>  obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
> +obj-$(CONFIG_TI_CPSW_CTRL_MACID) += cpsw-ctrl-macid.o
>  obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
>  ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
> diff --git a/drivers/net/ethernet/ti/cpsw-ctrl-macid.c 
> b/drivers/net/ethernet/ti/cpsw-ctrl-macid.c
> new file mode 100644
> index 000..e18c957
> --- /dev/null
> +++ b/drivers/net/ethernet/ti/cpsw-ctrl-macid.c
> @@ -0,0 +1,138 @@
> +/* CPSW Control Module MACID driver
> + *
> + * Copyright (C) 2013 Markus Pargmann 
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cpsw.h"
> +

Re: [PATCH 4/6] net: cpsw: Use cpsw-ctrl-macid driver

2014-02-13 Thread Uwe Kleine-König
Hello Markus,

On Wed, Dec 18, 2013 at 05:47:20PM +0100, Markus Pargmann wrote:
> Use ctrl-macid driver to obtain the macids stored in the processor. This
> is only done when defined in DT.
> 
> Signed-off-by: Markus Pargmann 
> ---
>  Documentation/devicetree/bindings/net/cpsw.txt |  5 +
>  drivers/net/ethernet/ti/cpsw.c | 18 ++
>  drivers/net/ethernet/ti/cpsw.h |  2 ++
>  3 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
> b/Documentation/devicetree/bindings/net/cpsw.txt
> index c39f077..b95c38b 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -34,6 +34,11 @@ Required properties:
>  Optional properties:
>  - dual_emac_res_vlan : Specifies VID to be used to segregate the ports
>  - mac-address: Specifies slave MAC address
> +- ti,mac-address-ctrl: When cpsw-ctrl-macid support is compiledin, 
> this can
> +   be set to a phandle with one argument, see
> +   cpsw-ctrl-macid.txt. If this method fails, cpsw falls
> +   back to mac-address or random mac-address.
> +
>  
>  Note: "ti,hwmods" field is used to fetch the base address and irq
>  resources from TI, omap hwmod data base during device registration.
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 5120d9c..382d793 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -1804,9 +1804,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
> *data,
>   snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
>PHY_ID_FMT, mdio->name, phyid);
>  
> - mac_addr = of_get_mac_address(slave_node);
> - if (mac_addr)
> - memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
> + ret = cpsw_ctrl_macid_read(slave_node, slave_data->mac_addr);
> + if (ret) {
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + mac_addr = of_get_mac_address(slave_node);
> + if (mac_addr)
> + memcpy(slave_data->mac_addr, mac_addr,
> + ETH_ALEN);
> + }
I'd do it the other way round: Use the contents from an explicit
"mac-address" or "local-mac-address" property (i.e. of_get_mac_address)
and if that doesn't return anything use the mac-address-ctrl as
fallback.

>  
>   slave_data->phy_if = of_get_phy_mode(slave_node);
>  
> @@ -1946,10 +1953,13 @@ static int cpsw_probe(struct platform_device *pdev)
>   /* Select default pin state */
>   pinctrl_pm_select_default_state(&pdev->dev);
>  
> - if (cpsw_probe_dt(&priv->data, pdev)) {
> + ret = cpsw_probe_dt(&priv->data, pdev);
> + if (ret == -EINVAL) {
>   pr_err("cpsw: platform data missing\n");
>   ret = -ENODEV;
>   goto clean_runtime_disable_ret;
> + } else if (ret) {
> + goto clean_runtime_disable_ret;
>   }
>   data = &priv->data;
>  
> diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
> index 1b71067..222eebe 100644
> --- a/drivers/net/ethernet/ti/cpsw.h
> +++ b/drivers/net/ethernet/ti/cpsw.h
> @@ -42,4 +42,6 @@ struct cpsw_platform_data {
>  
>  void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
>  
> +int cpsw_ctrl_macid_read(struct device_node *np, u8 *mac_addr);
> +
>  #endif /* __CPSW_H__ */
> -- 

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] net: cpsw: Support for am335x chip MACIDs

2014-02-13 Thread Uwe Kleine-König
Hello,

On Wed, Dec 18, 2013 at 11:13:01AM -0600, Felipe Balbi wrote:
> On Wed, Dec 18, 2013 at 10:40:58PM +0530, Mugunthan V N wrote:
> > On Wednesday 18 December 2013 10:38 PM, Felipe Balbi wrote:
> > > On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote:
> > >> On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote:
> > >> Mac ID is to be filled by U-Boot and this kind of approach is already
> > >> rejected in linux-omap list.
> > >>
> > >> If proper ethaddr/eth*addr is populated in U-boot environment variable
> > >> then mac-address dt property in ethernet* device nodes will be populated
> > >> before boot kernel in U-boot. So I don't think this patch series is
> > >> required.
> > > but will u-boot read MACID from control module ?
> > >
> > Yes, U-Boot will read the MACID from control module and if a customer
> > wants to have his own MACID, U-boot ENV variable ethaddr/eth1addr must
> > be updated.
> 
> cool, then I agree this series shouldn't be applied ;-)
But even then I'd suggest to take at least patches 1 and 2.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe 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] ARM: dts: OMAP3: Update ISP IOMMU node

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

Update the IOMMU node for the camera subsystem as per the
OMAP IOMMU bindings.

Signed-off-by: Florian Vaussard 
[s-a...@ti.com: corrected interrupt number]
Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/omap3.dtsi | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..ac91cc3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -411,10 +411,12 @@
};
 
mmu_isp: mmu@480bd400 {
-   compatible = "ti,omap3-mmu-isp";
-   ti,hwmods = "mmu_isp";
+   compatible = "ti,omap2-iommu";
reg = <0x480bd400 0x80>;
-   interrupts = <8>;
+   interrupts = <24>;
+   ti,hwmods = "mmu_isp";
+   ti,#tlb-entries = <8>;
+   dma-window = <0 0xf000>;
};
 
wdt2: wdt@48314000 {
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 05/16] iommu/omap: enable bus-error back on supported iommus

2014-02-13 Thread Suman Anna
The remoteproc MMUs in OMAP4+ SoCs have some additional debug
registers that can give out the PC value in addition to the
MMU fault address. The PC value can be extracted properly only
on the DSP cores, and is not available on the ARM processors
within the IPU sub-systems. Instead, the MMUs have been enhanced
to throw a bus-error response back to the IPU processors.

This functionality is programmable through the MMU_GP_REG register.
The cores are simply stalled if the MMU_GP_REG.BUS_ERR_BACK_EN bit
is not set. When set, a bus-error exception is raised allowing the
processor to handle it as a bus fault and provide additional debug
information. This feature is turned on by default by the driver on
iommus supporting it.

Signed-off-by: Subramaniam Chanderashekarapuram 
Signed-off-by: Suman Anna 
---
 drivers/iommu/omap-iommu.c  | 2 ++
 drivers/iommu/omap-iommu.h  | 5 +
 drivers/iommu/omap-iommu2.c | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 4329ab1..e64025a 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -964,6 +964,8 @@ static int omap_iommu_probe(struct platform_device *pdev)
if (err != 0)
return err;
obj->da_end = obj->da_start + len;
+   if (of_find_property(of, "ti,iommu-bus-err-back", NULL))
+   obj->has_bus_err_back = MMU_GP_REG_BUS_ERR_BACK_EN;
} else {
obj->nr_tlb_entries = pdata->nr_tlb_entries;
obj->name = pdata->name;
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 1200842..ea920c3 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -52,6 +52,8 @@ struct omap_iommu {
void *ctx; /* iommu context: registres saved area */
u32 da_start;
u32 da_end;
+
+   int has_bus_err_back;
 };
 
 struct cr_regs {
@@ -130,6 +132,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct 
device *dev)
 #define MMU_READ_CAM   0x68
 #define MMU_READ_RAM   0x6c
 #define MMU_EMU_FAULT_AD   0x70
+#define MMU_GP_REG 0x88
 
 #define MMU_REG_SIZE   256
 
@@ -163,6 +166,8 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct 
device *dev)
 #define MMU_RAM_MIXED_MASK (1 << MMU_RAM_MIXED_SHIFT)
 #define MMU_RAM_MIXED  MMU_RAM_MIXED_MASK
 
+#define MMU_GP_REG_BUS_ERR_BACK_EN 0x1
+
 /*
  * utilities for super page(16MB, 1MB, 64KB and 4KB)
  */
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index d745094..5e1ea3b 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -98,6 +98,9 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
 
iommu_write_reg(obj, pa, MMU_TTB);
 
+   if (obj->has_bus_err_back)
+   iommu_write_reg(obj, MMU_GP_REG_BUS_ERR_BACK_EN, MMU_GP_REG);
+
__iommu_set_twl(obj, true);
 
return 0;
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 09/16] ARM: OMAP2+: change the ISP device archdata MMU name

2014-02-13 Thread Suman Anna
The IOMMU DT adaptation support uses the device name instead
of an iommu object name. The iommu object names should eventually
vanish when all the IOMMU users have been converted to DT nodes.

NOTE: This change is not compatible with legacy boots, but OMAP3
is expected to be DT-boot only going forward.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/devices.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0dd6398..3bf0452 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -224,7 +224,7 @@ static struct platform_device omap3isp_device = {
 };
 
 static struct omap_iommu_arch_data omap3_isp_iommu = {
-   .name = "mmu_isp",
+   .name = "480bd400.mmu",
 };
 
 int omap3_init_camera(struct isp_platform_data *pdata)
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 14/16] ARM: OMAP3: hwmod data: cleanup data for IOMMUs

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

The irq numbers, ocp address space and device attribute data
have all been cleaned up for OMAP3 IOMMUs. All this data is
populated via the corresponding dt node.

Signed-off-by: Florian Vaussard 
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 46 --
 1 file changed, 46 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9c7e23a..d68c131 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -24,7 +24,6 @@
 #include "l4_3xxx.h"
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -2991,83 +2990,39 @@ static struct omap_hwmod_class omap3xxx_mmu_hwmod_class 
= {
 
 /* mmu isp */
 
-static struct omap_mmu_dev_attr mmu_isp_dev_attr = {
-   .da_start   = 0x0,
-   .da_end = 0xf000,
-   .nr_tlb_entries = 8,
-};
-
 static struct omap_hwmod omap3xxx_mmu_isp_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_isp_irqs[] = {
-   { .irq = 24 + OMAP_INTC_START, },
-   { .irq = -1 }
-};
-
-static struct omap_hwmod_addr_space omap3xxx_mmu_isp_addrs[] = {
-   {
-   .pa_start   = 0x480bd400,
-   .pa_end = 0x480bd47f,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
 
 /* l4_core -> mmu isp */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = {
.master = &omap3xxx_l4_core_hwmod,
.slave  = &omap3xxx_mmu_isp_hwmod,
-   .addr   = omap3xxx_mmu_isp_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.name   = "mmu_isp",
.class  = &omap3xxx_mmu_hwmod_class,
-   .mpu_irqs   = omap3xxx_mmu_isp_irqs,
.main_clk   = "cam_ick",
-   .dev_attr   = &mmu_isp_dev_attr,
.flags  = HWMOD_NO_IDLEST,
 };
 
 /* mmu iva */
 
-static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
-   .da_start   = 0x1100,
-   .da_end = 0xf000,
-   .nr_tlb_entries = 32,
-};
-
 static struct omap_hwmod omap3xxx_mmu_iva_hwmod;
-static struct omap_hwmod_irq_info omap3xxx_mmu_iva_irqs[] = {
-   { .irq = 28 + OMAP_INTC_START, },
-   { .irq = -1 }
-};
-
 static struct omap_hwmod_rst_info omap3xxx_mmu_iva_resets[] = {
{ .name = "mmu", .rst_shift = 1, .st_shift = 9 },
 };
 
-static struct omap_hwmod_addr_space omap3xxx_mmu_iva_addrs[] = {
-   {
-   .pa_start   = 0x5d00,
-   .pa_end = 0x5d7f,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
-
 /* l3_main -> iva mmu */
 static struct omap_hwmod_ocp_if omap3xxx_l3_main__mmu_iva = {
.master = &omap3xxx_l3_main_hwmod,
.slave  = &omap3xxx_mmu_iva_hwmod,
-   .addr   = omap3xxx_mmu_iva_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
 static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.name   = "mmu_iva",
.class  = &omap3xxx_mmu_hwmod_class,
-   .mpu_irqs   = omap3xxx_mmu_iva_irqs,
.clkdm_name = "iva2_clkdm",
.rst_lines  = omap3xxx_mmu_iva_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
@@ -3080,7 +3035,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT,
},
},
-   .dev_attr   = &mmu_iva_dev_attr,
.flags  = HWMOD_NO_IDLEST,
 };
 
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] ARM: dts: OMAP3: Add IVA IOMMU node

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

Add the DT node for the IOMMU within the DSP subsystem. The entry
is disabled to keep in line with the current hwmod usage.

Signed-off-by: Florian Vaussard 
[s-a...@ti.com: split the entry and disable the node]
Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/omap3.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ac91cc3..9607187 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -419,6 +419,15 @@
dma-window = <0 0xf000>;
};
 
+   mmu_iva: mmu@5d00 {
+   compatible = "ti,omap2-iommu";
+   reg = <0x5d00 0x80>;
+   interrupts = <28>;
+   ti,hwmods = "mmu_iva";
+   dma-window = <0x1100 0xeefff000>;
+   status = "disabled";
+   };
+
wdt2: wdt@48314000 {
compatible = "ti,omap3-wdt";
reg = <0x48314000 0x80>;
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/4] OMAP IOMMU DTS nodes

2014-02-13 Thread Suman Anna
Hi,

This series includes patches that adds the iommu DT nodes on
OMAP3 (IVA), and OMAP4 and OMAP5 SoCs. It also includes an
updated OMAP3 ISP iommu DT node patch posted previously [1].

Posting the series separately from the driver DT adapation
changes [2]. The series adds the DTS patches in line with the
new OMAP IOMMU bindings [3] posted alongside the DT adaptation.

[1] http://marc.info/?l=linux-omap&m=138728486000628&w=2
[2] http://marc.info/?l=linux-omap&m=139231544416973&w=2
[3] http://marc.info/?l=linux-omap&m=139231545116981&w=2

Florian Vaussard (3):
  ARM: dts: OMAP3: Update ISP IOMMU node
  ARM: dts: OMAP3: Add IVA IOMMU node
  ARM: dts: OMAP4: Add IOMMU nodes

Suman Anna (1):
  ARM: dts: OMAP5: Add IOMMU nodes

 arch/arm/boot/dts/omap3.dtsi | 17 ++---
 arch/arm/boot/dts/omap4.dtsi | 17 +
 arch/arm/boot/dts/omap5.dtsi | 17 +
 3 files changed, 48 insertions(+), 3 deletions(-)

-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/4] ARM: dts: OMAP4: Add IOMMU nodes

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

Add the IOMMU nodes for the DSP and IPU subsystems. The external
address space for DSP starts at 0x2000 in OMAP4 compared to
0x1100 in OMAP3, and the addresses beyond 0xE000 are
private address space for the Cortex-M3 cores in the IPU subsystem.
The MMU within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.

Signed-off-by: Florian Vaussard 
[s-a...@ti.com: dma-window updates and bus error back addition]
Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/omap4.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..1885f90 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -461,6 +461,23 @@
dma-names = "tx", "rx";
};
 
+   mmu_dsp: mmu@4a066000 {
+   compatible = "ti,omap4-iommu";
+   reg = <0x4a066000 0xff>;
+   interrupts = ;
+   ti,hwmods = "mmu_dsp";
+   dma-window = <0x2000 0xd000>;
+   };
+
+   mmu_ipu: mmu@55082000 {
+   compatible = "ti,omap4-iommu";
+   reg = <0x55082000 0xff>;
+   interrupts = ;
+   ti,hwmods = "mmu_ipu";
+   dma-window = <0 0xd000>;
+   ti,iommu-bus-err-back;
+   };
+
wdt2: wdt@4a314000 {
compatible = "ti,omap4-wdt", "ti,omap3-wdt";
reg = <0x4a314000 0x80>;
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP5: Add IOMMU nodes

2014-02-13 Thread Suman Anna
The IOMMU DT nodes have been added for the DSP and IPU
subsystems. The MMUs in OMAP5 are identical to those in
OMAP4, including the bus error back capability on IPU.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/omap5.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..a78fdaa 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,23 @@
dma-names = "tx", "rx";
};
 
+   mmu_dsp: mmu@4a066000 {
+   compatible = "ti,omap4-iommu";
+   reg = <0x4a066000 0xff>;
+   interrupts = ;
+   ti,hwmods = "mmu_dsp";
+   dma-window = <0x2000 0xd000>;
+   };
+
+   mmu_ipu: mmu@55082000 {
+   compatible = "ti,omap4-iommu";
+   reg = <0x55082000 0xff>;
+   interrupts = ;
+   ti,hwmods = "mmu_ipu";
+   dma-window = <0 0xd000>;
+   ti,iommu-bus-err-back;
+   };
+
keypad: keypad@4ae1c000 {
compatible = "ti,omap4-keypad";
reg = <0x4ae1c000 0x400>;
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.

Cc: Paul Walmsley 
Signed-off-by: Florian Vaussard 
[s-a...@ti.com: revise commit log]
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 
 arch/arm/plat-omap/Kconfig | 3 ---
 2 files changed, 11 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 4c3b1e6..81dd071 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3029,8 +3029,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.flags  = HWMOD_NO_IDLEST,
 };
 
-#ifdef CONFIG_OMAP_IOMMU_IVA2
-
 /* mmu iva */
 
 static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
@@ -3082,8 +3080,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.flags  = HWMOD_NO_IDLEST,
 };
 
-#endif
-
 /* l4_per -> gpio4 */
 static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3855,9 +3851,7 @@ static struct omap_hwmod_ocp_if *omap34xx_hwmod_ocp_ifs[] 
__initdata = {
&omap3xxx_l4_core__hdq1w,
&omap3xxx_sad2d__l3,
&omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
&omap3xxx_l3_main__mmu_iva,
-#endif
&omap34xx_l4_core__ssi,
NULL
 };
@@ -3881,9 +3875,7 @@ static struct omap_hwmod_ocp_if *omap36xx_hwmod_ocp_ifs[] 
__initdata = {
&omap3xxx_l4_core__hdq1w,
&omap3xxx_sad2d__l3,
&omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
&omap3xxx_l3_main__mmu_iva,
-#endif
NULL
 };
 
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 436ea97..02fc10d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -86,9 +86,6 @@ config OMAP_MUX_WARNINGS
  to change the pin multiplexing setup.  When there are no warnings
  printed, it's safe to deselect OMAP_MUX for your product.
 
-config OMAP_IOMMU_IVA2
-   bool
-
 config OMAP_MPU_TIMER
bool "Use mpu timer"
depends on ARCH_OMAP1
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 04/16] iommu/omap: add devicetree support

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

As OMAP2+ is moving to a full DT boot for all SoC families, commit
7ce93f3 "ARM: OMAP2+: Fix more missing data for omap3.dtsi file"
adds basic DT bits for OMAP3. But the driver is not yet converted,
so this will not work and driver will not be probed. Convert it!

Signed-off-by: Florian Vaussard 
[s-a...@ti.com: dev_name adaptation and improved error checking]
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap-iommu.c |  5 +
 drivers/iommu/omap-iommu.c   | 41 
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f6daae8..f1fab56 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +59,10 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, 
void *unused)
 
 static int __init omap_iommu_init(void)
 {
+   /* If dtb is there, the devices will be created dynamically */
+   if (of_have_populated_dt())
+   return -ENODEV;
+
return omap_hwmod_for_each_by_class("mmu", omap_iommu_dev_init, NULL);
 }
 /* must be ready before omap3isp is probed */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6272c36..4329ab1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -23,6 +23,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -937,20 +940,41 @@ static int omap_iommu_probe(struct platform_device *pdev)
 {
int err = -ENODEV;
int irq;
+   size_t len;
struct omap_iommu *obj;
struct resource *res;
struct iommu_platform_data *pdata = pdev->dev.platform_data;
+   struct device_node *of = pdev->dev.of_node;
 
obj = devm_kzalloc(&pdev->dev, sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
 
-   obj->nr_tlb_entries = pdata->nr_tlb_entries;
-   obj->name = pdata->name;
+   if (of) {
+   obj->name = dev_name(&pdev->dev);
+   obj->nr_tlb_entries = 32;
+   err = of_property_read_u32(of, "ti,#tlb-entries",
+  &obj->nr_tlb_entries);
+   if (err && err != -EINVAL)
+   return err;
+   if (obj->nr_tlb_entries != 32 && obj->nr_tlb_entries != 8)
+   return -EINVAL;
+   err = of_get_dma_window(of, NULL, 0, NULL, &obj->da_start,
+   &len);
+   if (err != 0)
+   return err;
+   obj->da_end = obj->da_start + len;
+   } else {
+   obj->nr_tlb_entries = pdata->nr_tlb_entries;
+   obj->name = pdata->name;
+   obj->da_start = pdata->da_start;
+   obj->da_end = pdata->da_end;
+   }
+   if (obj->da_end <= obj->da_start)
+   return -EINVAL;
+
obj->dev = &pdev->dev;
obj->ctx = (void *)obj + sizeof(*obj);
-   obj->da_start = pdata->da_start;
-   obj->da_end = pdata->da_end;
 
spin_lock_init(&obj->iommu_lock);
mutex_init(&obj->mmap_lock);
@@ -991,11 +1015,20 @@ static int omap_iommu_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static struct of_device_id omap_iommu_of_match[] = {
+   { .compatible = "ti,omap2-iommu" },
+   { .compatible = "ti,omap4-iommu" },
+   { .compatible = "ti,dra7-iommu" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+
 static struct platform_driver omap_iommu_driver = {
.probe  = omap_iommu_probe,
.remove = omap_iommu_remove,
.driver = {
.name   = "omap-iommu",
+   .of_match_table = of_match_ptr(omap_iommu_of_match),
},
 };
 
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 16/16] ARM: OMAP2+: Remove legacy omap-iommu.c

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

With full DT boot, the legacy mode of platform device creation
for OMAP IOMMUs is not needed anymore.

Signed-off-by: Florian Vaussard 
---
 arch/arm/mach-omap2/Makefile |  3 --
 arch/arm/mach-omap2/omap-iommu.c | 79 
 2 files changed, 82 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/omap-iommu.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e6eec6f..242933f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -226,9 +226,6 @@ obj-$(CONFIG_SOC_DRA7XX)+= omap_hwmod_7xx_data.o
 obj-$(CONFIG_OMAP3_EMU)+= emu.o
 obj-$(CONFIG_HW_PERF_EVENTS)   += pmu.o
 
-iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
-obj-y  += $(iommu-m) $(iommu-y)
-
 ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y  += dsp.o
 endif
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
deleted file mode 100644
index f1fab56..000
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ /dev/null
@@ -1,79 +0,0 @@
-/*
- * omap iommu: omap device registration
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU 
- *
- * 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 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include "soc.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-
-static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
-{
-   struct platform_device *pdev;
-   struct iommu_platform_data *pdata;
-   struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh->dev_attr;
-   static int i;
-
-   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
-   if (!pdata)
-   return -ENOMEM;
-
-   pdata->name = oh->name;
-   pdata->nr_tlb_entries = a->nr_tlb_entries;
-   pdata->da_start = a->da_start;
-   pdata->da_end = a->da_end;
-
-   if (oh->rst_lines_cnt == 1) {
-   pdata->reset_name = oh->rst_lines->name;
-   pdata->assert_reset = omap_device_assert_hardreset;
-   pdata->deassert_reset = omap_device_deassert_hardreset;
-   }
-
-   pdev = omap_device_build("omap-iommu", i, oh, pdata, sizeof(*pdata));
-
-   kfree(pdata);
-
-   if (IS_ERR(pdev)) {
-   pr_err("%s: device build err: %ld\n", __func__, PTR_ERR(pdev));
-   return PTR_ERR(pdev);
-   }
-
-   i++;
-
-   return 0;
-}
-
-static int __init omap_iommu_init(void)
-{
-   /* If dtb is there, the devices will be created dynamically */
-   if (of_have_populated_dt())
-   return -ENODEV;
-
-   return omap_hwmod_for_each_by_class("mmu", omap_iommu_dev_init, NULL);
-}
-/* must be ready before omap3isp is probed */
-omap_subsys_initcall(omap_iommu_init);
-
-static void __exit omap_iommu_exit(void)
-{
-   /* Do nothing */
-}
-module_exit(omap_iommu_exit);
-
-MODULE_AUTHOR("Hiroshi DOYU");
-MODULE_DESCRIPTION("omap iommu: omap device registration");
-MODULE_LICENSE("GPL v2");
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 11/16] ARM: OMAP3: fix iva mmu programming issues

2014-02-13 Thread Suman Anna
The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in RET, and there
is no automatic power domain switching to ON.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c 
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index e6b91e5..f03dc97 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -247,7 +247,7 @@ static struct clockdomain neon_clkdm = {
 static struct clockdomain iva2_clkdm = {
.name   = "iva2_clkdm",
.pwrdm  = { .name = "iva2_pwrdm" },
-   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .flags  = CLKDM_CAN_SWSUP,
.dep_bit= OMAP3430_PM_WKDEP_MPU_EN_IVA2_SHIFT,
.wkdep_srcs = iva2_wkdeps,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 81dd071..9c7e23a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3068,12 +3068,16 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.name   = "mmu_iva",
.class  = &omap3xxx_mmu_hwmod_class,
.mpu_irqs   = omap3xxx_mmu_iva_irqs,
+   .clkdm_name = "iva2_clkdm",
.rst_lines  = omap3xxx_mmu_iva_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
.main_clk   = "iva2_ck",
.prcm = {
.omap2 = {
.module_offs = OMAP3430_IVA2_MOD,
+   .module_bit = OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_SHIFT,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT,
},
},
.dev_attr   = &mmu_iva_dev_attr,
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 15/16] ARM: OMAP4: hwmod data: cleanup data for IOMMUs

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

The device attribute data and ocp address space have all been
cleaned up for OMAP4 iommus. All this data is populated via
the corresponding dt node.

Signed-off-by: Florian Vaussard 
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 35 --
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3318cae9..caca6c2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -29,7 +29,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include "omap_hwmod.h"
@@ -2083,32 +2082,16 @@ static struct omap_hwmod_class omap44xx_mmu_hwmod_class 
= {
 
 /* mmu ipu */
 
-static struct omap_mmu_dev_attr mmu_ipu_dev_attr = {
-   .da_start   = 0x0,
-   .da_end = 0xf000,
-   .nr_tlb_entries = 32,
-};
-
 static struct omap_hwmod omap44xx_mmu_ipu_hwmod;
 static struct omap_hwmod_rst_info omap44xx_mmu_ipu_resets[] = {
{ .name = "mmu_cache", .rst_shift = 2 },
 };
 
-static struct omap_hwmod_addr_space omap44xx_mmu_ipu_addrs[] = {
-   {
-   .pa_start   = 0x55082000,
-   .pa_end = 0x550820ff,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
-
 /* l3_main_2 -> mmu_ipu */
 static struct omap_hwmod_ocp_if omap44xx_l3_main_2__mmu_ipu = {
.master = &omap44xx_l3_main_2_hwmod,
.slave  = &omap44xx_mmu_ipu_hwmod,
.clk= "l3_div_ck",
-   .addr   = omap44xx_mmu_ipu_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
@@ -2127,37 +2110,20 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
.modulemode   = MODULEMODE_HWCTRL,
},
},
-   .dev_attr   = &mmu_ipu_dev_attr,
 };
 
 /* mmu dsp */
 
-static struct omap_mmu_dev_attr mmu_dsp_dev_attr = {
-   .da_start   = 0x0,
-   .da_end = 0xf000,
-   .nr_tlb_entries = 32,
-};
-
 static struct omap_hwmod omap44xx_mmu_dsp_hwmod;
 static struct omap_hwmod_rst_info omap44xx_mmu_dsp_resets[] = {
{ .name = "mmu_cache", .rst_shift = 1 },
 };
 
-static struct omap_hwmod_addr_space omap44xx_mmu_dsp_addrs[] = {
-   {
-   .pa_start   = 0x4a066000,
-   .pa_end = 0x4a0660ff,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
-
 /* l4_cfg -> dsp */
 static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mmu_dsp = {
.master = &omap44xx_l4_cfg_hwmod,
.slave  = &omap44xx_mmu_dsp_hwmod,
.clk= "l4_div_ck",
-   .addr   = omap44xx_mmu_dsp_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
@@ -2176,7 +2142,6 @@ static struct omap_hwmod omap44xx_mmu_dsp_hwmod = {
.modulemode   = MODULEMODE_HWCTRL,
},
},
-   .dev_attr   = &mmu_dsp_dev_attr,
 };
 
 /*
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 13/16] ARM: OMAP2+: extend iommu pdata-quirks to OMAP5

2014-02-13 Thread Suman Anna
OMAP5 has the same iommus as OMAP4, so extend the OMAP4
iommu pdata quirks for OMAP5 as well.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/pdata-quirks.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 74e094a..551877f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -193,7 +193,9 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
 }
+#endif
 
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 static struct iommu_platform_data omap4_iommu_pdata = {
.reset_name = "mmu_cache",
.assert_reset = omap_device_assert_hardreset,
@@ -264,6 +266,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 #ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux", 
&pcs_pdata),
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux", 
&pcs_pdata),
+#endif
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
   &omap4_iommu_pdata),
OF_DEV_AUXDATA("ti,omap4-iommu", 0x55082000, "55082000.mmu",
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 07/16] iommu/omap: allow enable/disable even without pdata

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.

Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use pdata-quirks as a
transitional solution.

Signed-off-by: Florian Vaussard 
---
 drivers/iommu/omap-iommu.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f6afe8f..7672eb4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -149,13 +149,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj->dev);
struct iommu_platform_data *pdata = pdev->dev.platform_data;
 
-   if (!pdata)
-   return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
 
-   if (pdata->deassert_reset) {
+   if (pdata && pdata->deassert_reset) {
err = pdata->deassert_reset(pdev, pdata->reset_name);
if (err) {
dev_err(obj->dev, "deassert_reset failed: %d\n", err);
@@ -175,14 +172,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj->dev);
struct iommu_platform_data *pdata = pdev->dev.platform_data;
 
-   if (!pdata)
-   return;
-
arch_iommu->disable(obj);
 
pm_runtime_put_sync(obj->dev);
 
-   if (pdata->assert_reset)
+   if (pdata && pdata->assert_reset)
pdata->assert_reset(pdev, pdata->reset_name);
 }
 
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 03/16] Documentation: dt: add OMAP iommu bindings

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.

Signed-off-by: Florian Vaussard 
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna 
---
 .../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt 
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
new file mode 100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+   "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances
+   "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances
+   "ti,dra7-iommu" for DRA7xx IOMMU instances
+- ti,hwmods  : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
+
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
+Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+ back a bus error response on MMU faults.
+
+Example:
+   /* OMAP3 ISP MMU */
+   mmu_isp: mmu@480bd400 {
+   compatible = "ti,omap2-iommu";
+   reg = <0x480bd400 0x80>;
+   interrupts = <24>;
+   ti,hwmods = "mmu_isp";
+   ti,#tlb-entries = <8>;
+   dma-window = <0 0xf000>;
+   };
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 01/16] iommu/omap: convert to devm_* interfaces

2014-02-13 Thread Suman Anna
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions.

Signed-off-by: Florian Vaussard 
Signed-off-by: Suman Anna 
---
 drivers/iommu/omap-iommu.c | 52 +-
 1 file changed, 10 insertions(+), 42 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..fff2ffd 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -941,7 +941,7 @@ static int omap_iommu_probe(struct platform_device *pdev)
struct resource *res;
struct iommu_platform_data *pdata = pdev->dev.platform_data;
 
-   obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
+   obj = devm_kzalloc(&pdev->dev, sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
 
@@ -958,33 +958,18 @@ static int omap_iommu_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&obj->mmap);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   err = -ENODEV;
-   goto err_mem;
-   }
-
-   res = request_mem_region(res->start, resource_size(res),
-dev_name(&pdev->dev));
-   if (!res) {
-   err = -EIO;
-   goto err_mem;
-   }
-
-   obj->regbase = ioremap(res->start, resource_size(res));
-   if (!obj->regbase) {
-   err = -ENOMEM;
-   goto err_ioremap;
-   }
+   obj->regbase = devm_ioremap_resource(obj->dev, res);
+   if (IS_ERR(obj->regbase))
+   return PTR_ERR(obj->regbase);
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   err = -ENODEV;
-   goto err_irq;
-   }
-   err = request_irq(irq, iommu_fault_handler, IRQF_SHARED,
- dev_name(&pdev->dev), obj);
+   if (irq < 0)
+   return -ENODEV;
+
+   err = devm_request_irq(obj->dev, irq, iommu_fault_handler, IRQF_SHARED,
+  dev_name(obj->dev), obj);
if (err < 0)
-   goto err_irq;
+   return err;
platform_set_drvdata(pdev, obj);
 
pm_runtime_irq_safe(obj->dev);
@@ -992,34 +977,17 @@ static int omap_iommu_probe(struct platform_device *pdev)
 
dev_info(&pdev->dev, "%s registered\n", obj->name);
return 0;
-
-err_irq:
-   iounmap(obj->regbase);
-err_ioremap:
-   release_mem_region(res->start, resource_size(res));
-err_mem:
-   kfree(obj);
-   return err;
 }
 
 static int omap_iommu_remove(struct platform_device *pdev)
 {
-   int irq;
-   struct resource *res;
struct omap_iommu *obj = platform_get_drvdata(pdev);
 
iopgtable_clear_entry_all(obj);
 
-   irq = platform_get_irq(pdev, 0);
-   free_irq(irq, obj);
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   release_mem_region(res->start, resource_size(res));
-   iounmap(obj->regbase);
-
pm_runtime_disable(obj->dev);
 
dev_info(&pdev->dev, "%s removed\n", obj->name);
-   kfree(obj);
return 0;
 }
 
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 12/16] ARM: OMAP5: hwmod data: add mmu data for ipu & dsp

2014-02-13 Thread Suman Anna
A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83 ++
 1 file changed, 83 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..8923172 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1122,6 +1122,71 @@ static struct omap_hwmod omap54xx_mmc5_hwmod = {
 };
 
 /*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mmu_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_mmu_hwmod_class = {
+   .name = "mmu",
+   .sysc = &omap54xx_mmu_sysc,
+};
+
+static struct omap_hwmod_rst_info omap54xx_mmu_dsp_resets[] = {
+   { .name = "mmu_cache", .rst_shift = 1 },
+};
+
+static struct omap_hwmod omap54xx_mmu_dsp_hwmod = {
+   .name   = "mmu_dsp",
+   .class  = &omap54xx_mmu_hwmod_class,
+   .clkdm_name = "dsp_clkdm",
+   .rst_lines  = omap54xx_mmu_dsp_resets,
+   .rst_lines_cnt  = ARRAY_SIZE(omap54xx_mmu_dsp_resets),
+   .main_clk   = "dpll_iva_h11x2_ck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET,
+   .rstctrl_offs = OMAP54XX_RM_DSP_RSTCTRL_OFFSET,
+   .context_offs = OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
+/* mmu ipu */
+static struct omap_hwmod_rst_info omap54xx_mmu_ipu_resets[] = {
+   { .name = "mmu_cache", .rst_shift = 2 },
+};
+
+static struct omap_hwmod omap54xx_mmu_ipu_hwmod = {
+   .name   = "mmu_ipu",
+   .class  = &omap54xx_mmu_hwmod_class,
+   .clkdm_name = "ipu_clkdm",
+   .rst_lines  = omap54xx_mmu_ipu_resets,
+   .rst_lines_cnt  = ARRAY_SIZE(omap54xx_mmu_ipu_resets),
+   .main_clk   = "dpll_core_h22x2_ck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = OMAP54XX_CM_IPU_IPU_CLKCTRL_OFFSET,
+   .rstctrl_offs = OMAP54XX_RM_IPU_RSTCTRL_OFFSET,
+   .context_offs = OMAP54XX_RM_IPU_IPU_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
+/*
  * 'mpu' class
  * mpu sub-system
  */
@@ -1763,6 +1828,14 @@ static struct omap_hwmod_ocp_if 
omap54xx_l4_cfg__l3_main_1 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> mmu_dsp */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mmu_dsp = {
+   .master = &omap54xx_l4_cfg_hwmod,
+   .slave  = &omap54xx_mmu_dsp_hwmod,
+   .clk= "l4_root_clk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* mpu -> l3_main_1 */
 static struct omap_hwmod_ocp_if omap54xx_mpu__l3_main_1 = {
.master = &omap54xx_mpu_hwmod,
@@ -1787,6 +1860,14 @@ static struct omap_hwmod_ocp_if 
omap54xx_l4_cfg__l3_main_2 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l3_main_2 -> mmu_ipu */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_2__mmu_ipu = {
+   .master = &omap54xx_l3_main_2_hwmod,
+   .slave  = &omap54xx_mmu_ipu_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l3_main_1 -> l3_main_3 */
 static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l3_main_3 = {
.master = &omap54xx_l3_main_1_hwmod,
@@ -2345,6 +2426,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] 
__initdata = {
&omap54xx_l4_wkup__counter_32k,
&omap54xx_l4_cfg__dma_system,
&omap54xx_l4_abe__dmic,
+   &omap54xx_l4_cfg__mmu_dsp,
&omap54xx_mpu__emif1,
&omap54xx_mpu__emif2,
&omap54xx_l4_wkup__gpio1,
@@ -2360,6 +2442,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] 
__initdata = {
&omap54xx_l4_per__i2c3,
&omap54xx_l4_per__i2c4,
&omap54xx_l4_per__i2c5,
+   &omap54xx_l3_main_2__mmu_ipu,
&omap54xx_l4_wkup__kbd,
&omap54xx_l4_cfg__mailbox,
&omap54xx_l4_abe__mcbsp1,
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscri

[PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL

2014-02-13 Thread Suman Anna
From: Florian Vaussard 

omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value (in
case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.

In such case, omap_iommu_attach() should return ENODEV, not NULL.

Signed-off-by: Florian Vaussard 
Acked-by: Suman Anna 
---
 drivers/iommu/omap-iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index fff2ffd..6272c36 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev, void 
*data)
  **/
 static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
 {
-   int err = -ENOMEM;
+   int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
 
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const char 
*name, u32 *iopgd)
(void *)name,
device_match_by_alias);
if (!dev)
-   return NULL;
+   return ERR_PTR(err);
 
obj = to_iommu(dev);
 
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 06/16] iommu/omap: allocate archdata on the fly for DT-based devices

2014-02-13 Thread Suman Anna
From: Laurent Pinchart 

The OMAP IOMMU driver locates the IOMMU associated to a device using the
IOMMU name stored in the device archdata iommu field. That field is
expected to be populated by platform code and is left unset for DT-based
devices. This results in a crash when the IOMMU driver attaches a domain
to a device.

Fix this by allocating the archdata iommu structure when devices are
added and freeing when they are removed. Devices without an OF node, and
devices without an iommus property in their OF node are ignored. The
iommu name is initialized from the IOMMU device node name.

This should be simplified when removing non-DT support completely from
the IOMMU users as the IOMMU name won't be needed anymore, and the
IOMMU device pointer could then be stored in the archdata iommu field
directly.

Signed-off-by: Laurent Pinchart 
[s-a...@ti.com: updated to use device name instead of OF name]
Signed-off-by: Suman Anna 
---
 drivers/iommu/omap-iommu.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index e64025a..f6afe8f 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1256,6 +1256,49 @@ static int omap_iommu_domain_has_cap(struct iommu_domain 
*domain,
return 0;
 }
 
+static int omap_iommu_add_device(struct device *dev)
+{
+   struct omap_iommu_arch_data *arch_data;
+   struct device_node *np;
+
+   /*
+* Allocate the archdata iommu structure for DT-based devices.
+*
+* TODO: Simplify this when removing non-DT support completely from the
+* IOMMU users.
+*/
+   if (!dev->of_node)
+   return 0;
+
+   np = of_parse_phandle(dev->of_node, "iommus", 0);
+   if (!np)
+   return 0;
+
+   arch_data = kzalloc(sizeof(*arch_data), GFP_KERNEL);
+   if (!arch_data) {
+   of_node_put(np);
+   return -ENOMEM;
+   }
+
+   arch_data->name = kstrdup(dev_name(dev), GFP_KERNEL);
+   dev->archdata.iommu = arch_data;
+
+   of_node_put(np);
+
+   return 0;
+}
+
+static void omap_iommu_remove_device(struct device *dev)
+{
+   struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+
+   if (!dev->of_node || !arch_data)
+   return;
+
+   kfree(arch_data->name);
+   kfree(arch_data);
+}
+
 static struct iommu_ops omap_iommu_ops = {
.domain_init= omap_iommu_domain_init,
.domain_destroy = omap_iommu_domain_destroy,
@@ -1265,6 +1308,8 @@ static struct iommu_ops omap_iommu_ops = {
.unmap  = omap_iommu_unmap,
.iova_to_phys   = omap_iommu_iova_to_phys,
.domain_has_cap = omap_iommu_domain_has_cap,
+   .add_device = omap_iommu_add_device,
+   .remove_device  = omap_iommu_remove_device,
.pgsize_bitmap  = OMAP_IOMMU_PGSIZES,
 };
 
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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 00/16] OMAP IOMMU DT adaptation and cleanup

2014-02-13 Thread Suman Anna
Hi,

This is an updated series to the initial OMAP IOMMU DT driver
adaptation series [1], that primarily dealt with just the OMAP3
ISP MMU. This series is based on 3.14-rc2, and the patches were
developed in collaboration with Florian. I am hoping that the
series can make the 3.15 merge window.

This series updates the bindings for IOMMUs for all OMAP2+ SoCs
(OMAP3, OMAP4, OMAP5, DRA7), and includes new patches for adding
the support to iommus on OMAP4 and OMAP5, and IVA IOMMU on OMAP3.
The DT bindings and adaptation is done mainly in patches 3 and 4.
The differences between IOMMUs between different OMAP generations
is explained in the previous posting [1], and the differentiation
is achieved through two optional properties keeping the compatible
strings to a minimum. This could also have been achieved through
driver match data with a compatible string per sub-system, so do
let me know if that should be the preferred approach.

All the MMUs other than the OMAP3 ISP leverage omap_device reset
functions, performed through platform data ops previously. With
the removal of the legacy mode, the same functionality is achieved
for DT nodes through pdata quirks until a TI PRCM reset driver is
available.

The first 7 patches in the series are in drivers/iommu, with all the
remaining patches in the arch/arm/mach-omap2 layer.

Tony,
The last 3 patches are cleanup of the legacy mode, so IOMMU devices
cannot be instantiated after these patches. Please let me know if
legacy mode on OMAP3 needs to be supported for 3.15, in which case,
the last 3 can be dropped for now and I would have to revise the OMAP3
ISP archdata change (Patch 9) to support both legacy and DT boots.
At present, I have made the change to support OMAP3 ISP with DT-boot
only.

Detailed changes in v2:
- Cleanup of driver probe/release to use devm_ interfaces (Patch 1)
- The DT bindings are split into a separate patch, and updated based
  on discussion on v1 [1] (Patch 3)
- Updated DT adaptation patch with improved error checking, and
  support for DRA7 compatible IOMMUs in the driver (Patch 4)
- Added support for throwing a bus error response back to the processor
  cores on MMUs associated with IPUs (Patch 5)
- Added preliminary support to DT-based IOMMU users (Patch 6)
- Added preparatory patches to enable and use the hwmod for IVA MMU
  on OMAP3 (Patches 8 and 11)
- Adapt the OMAP3 ISP archdata to support DT boot (Patch 9). Legacy
  mode will not work after this patch, and this will be cleaned up
  anyway once OMAP3ISP is converted to a DT node.
- Reset functionality enablement with DT-boots using pdata quirks
  for OMAP3 IVA, OMAP4 and OMAP5 DSP & IPU MMUs (Patches 10, 13)
- Added the basic hwmod data for OMAP5 iommus (Patch 12)
- Clean up the iommu hwmod data and remove the legacy file for creating
  IOMMU devices (Patches 14, 15, 16).
- Dropped the "iommu/omap: Do bus_set_iommu() only if probe() succeeds"
  patch from previous series.
- Dropped the OMAP3 ISP MMU DTS patch (posting separately).

I have validated the functionality of all the different IOMMUs on
OMAP3, OMAP4 and OMAP5. Florian has verified the OMAP3 ISP usage as
well. The full branch including the DTS patches is here for reference, 
https://github.com/sumananna/omap-kernel/commits/iommu/3.14-rc2-dt-support-v2

v1:
- Couple of cleanup and initial DT adaptation for OMAP3 ISP.
http://marc.info/?l=linux-omap&m=138728485600624&w=2

[1] http://marc.info/?l=linux-omap&m=138782819732435&w=2


Florian Vaussard (8):
  iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
  Documentation: dt: add OMAP iommu bindings
  iommu/omap: add devicetree support
  iommu/omap: allow enable/disable even without pdata
  ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
  ARM: OMAP3: hwmod data: cleanup data for IOMMUs
  ARM: OMAP4: hwmod data: cleanup data for IOMMUs
  ARM: OMAP2+: Remove legacy omap-iommu.c

Laurent Pinchart (1):
  iommu/omap: allocate archdata on the fly for DT-based devices

Suman Anna (7):
  iommu/omap: convert to devm_* interfaces
  iommu/omap: enable bus-error back on supported iommus
  ARM: OMAP2+: change the ISP device archdata MMU name
  ARM: OMAP2+: use pdata quirks for iommu reset lines
  ARM: OMAP3: fix iva mmu programming issues
  ARM: OMAP5: hwmod data: add mmu data for ipu & dsp
  ARM: OMAP2+: extend iommu pdata-quirks to OMAP5

 .../devicetree/bindings/iommu/ti,omap-iommu.txt|  28 
 arch/arm/mach-omap2/Makefile   |   3 -
 arch/arm/mach-omap2/clockdomains3xxx_data.c|   2 +-
 arch/arm/mach-omap2/devices.c  |   2 +-
 arch/arm/mach-omap2/omap-iommu.c   |  74 --
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  58 +---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  35 -
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  83 +++
 arch/arm/mach-omap2/pdata-quirks.c |  24 
 arch/arm/plat-omap/Kconfig |   3 -
 drivers/i

[PATCHv2 10/16] ARM: OMAP2+: use pdata quirks for iommu reset lines

2014-02-13 Thread Suman Anna
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.

This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 & OMAP4) and IPU subsystems (OMAP4).

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/pdata-quirks.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..74e094a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,12 +16,14 @@
 #include 
 
 #include 
+#include 
 
 #include "am35xx.h"
 #include "common.h"
 #include "common-board-devices.h"
 #include "dss-common.h"
 #include "control.h"
+#include "omap_device.h"
 
 struct pdata_init {
const char *compatible;
@@ -92,6 +94,12 @@ static void __init hsmmc2_internal_input_clk(void)
omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
 }
 
+static struct iommu_platform_data omap3_iommu_pdata = {
+   .reset_name = "mmu",
+   .assert_reset = omap_device_assert_hardreset,
+   .deassert_reset = omap_device_deassert_hardreset,
+};
+
 static int omap3_sbc_t3730_twl_callback(struct device *dev,
   unsigned gpio,
   unsigned ngpio)
@@ -185,6 +193,12 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
 }
+
+static struct iommu_platform_data omap4_iommu_pdata = {
+   .reset_name = "mmu_cache",
+   .assert_reset = omap_device_assert_hardreset,
+   .deassert_reset = omap_device_deassert_hardreset,
+};
 #endif
 
 #ifdef CONFIG_SOC_OMAP5
@@ -240,6 +254,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 #ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA("ti,omap3-padconf", 0x48002030, "48002030.pinmux", 
&pcs_pdata),
OF_DEV_AUXDATA("ti,omap3-padconf", 0x48002a00, "48002a00.pinmux", 
&pcs_pdata),
+   OF_DEV_AUXDATA("ti,omap2-iommu", 0x5d00, "5d00.mmu",
+  &omap3_iommu_pdata),
/* Only on am3517 */
OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", NULL),
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",
@@ -248,6 +264,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 #ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux", 
&pcs_pdata),
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux", 
&pcs_pdata),
+   OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
+  &omap4_iommu_pdata),
+   OF_DEV_AUXDATA("ti,omap4-iommu", 0x55082000, "55082000.mmu",
+  &omap4_iommu_pdata),
 #endif
{ /* sentinel */ },
 };
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP4: sleep: byteswap data for big-endian

2014-02-13 Thread Tony Lindgren
* Santosh Shilimkar  [140114 15:46]:
> On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote:
> 
> I haven't looked at patch myself but as you pointed out if it adds
> dead code and makes the code un-readable then probably that something
> we shouldn't merge.

Yeah it seems the assembly parts should be done in more generic
way using macros so the same setup can then be used for other
SoCs. For the other trivial changes, let's try to get them merged
to shrink down the patchset.

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 00/26] OMAP dma engine rework

2014-02-13 Thread Tony Lindgren
* Russell King - ARM Linux  [140210 07:58]:
> This is the current set of patches for the OMAP DMA engine rework,
> which should now work correctly on OMAP1 platforms thanks to Tony's
> testing.
> 
> It would be good to get this validated by others across a range of
> OMAP platforms, and queued up for the next merge window, so it can
> be built upon.
> 
> Acks appreciated, and once sufficient have been added, I'll send a
> pull request for this to Vinod.

Looks good to me and should not conflict with other patches
that I'm aware of. Please feel free to add:

Acked-by: Tony Lindgren 
--
To unsubscribe from this list: send the line "unsubscribe 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] [RESEND] ARM/dts: hdmi-codec: panda/es dt entries

2014-02-13 Thread Paolo Pisati
Signed-off-by: Paolo Pisati 
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
 arch/arm/boot/dts/omap4-panda-es.dts  |3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..f4aeaa1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -36,9 +36,15 @@
};
};
 
+   hdmi_audio: hdmi_audio@0 {
+   compatible = "linux,hdmi-audio";
+   status = "okay";
+   };
+
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
+   ti,audio-codec = <&hdmi_audio>;
 
ti,mclk-freq = <3840>;
 
@@ -57,7 +63,8 @@
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
};
 
/* HS USB Port 1 Power */
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..70152d6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -23,7 +23,8 @@
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
 };
 
 /* PandaboardES has external pullups on SCL & SDA */
-- 
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] ARM/dts: hdmi-codec: panda/es dt entries

2014-02-13 Thread Paolo Pisati
Signed-off-by: Paolo Pisati 
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
 arch/arm/boot/dts/omap4-panda-es.dts  |3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..f4aeaa1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -36,9 +36,15 @@
};
};
 
+   hdmi_audio: hdmi_audio@0 {
+   compatible = "linux,hdmi-audio";
+   status = "okay";
+   };
+
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
+   ti,audio-codec = <&hdmi_audio>;
 
ti,mclk-freq = <3840>;
 
@@ -57,7 +63,8 @@
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
};
 
/* HS USB Port 1 Power */
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..70152d6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -23,7 +23,8 @@
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
 };
 
 /* PandaboardES has external pullups on SCL & SDA */
-- 
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 4/4] Documentation: dt: OMAP: Update Overo/Tobi

2014-02-13 Thread Nishanth Menon
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Update the compatible string for Overo/Tobi to reflect the latest
> changes.
> 
> Signed-off-by: Florian Vaussard 
> ---
>  Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 34dc40c..af9b4a0 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -91,7 +91,7 @@ Boards:
>compatible = "ti,omap3-beagle", "ti,omap3"
>  
>  - OMAP3 Tobi with Overo : Commercial expansion board with daughter board
> -  compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
> +  compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
omap3-overo-storm-tobi.dts is not covered here, so, I wonder as the
number of boards supported keep increasing, is'nt it better we drop
the board information from omap.txt?

>  
>  - OMAP4 SDP : Software Development Board
>compatible = "ti,omap4-sdp", "ti,omap4430"
> 
-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/4] ARM: dts: omap3-tobi: Use the correct vendor prefix

2014-02-13 Thread Nishanth Menon
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Gumstix is the correct vendor for all Overo related products.
> 
> Reported-by: Javier Martinez Canillas 
> Signed-off-by: Florian Vaussard 
Acked-by: Nishanth Menon 
> ---
>  arch/arm/boot/dts/omap3-tobi.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-tobi.dts 
> b/arch/arm/boot/dts/omap3-tobi.dts
> index 0e3b8bf..c742afa 100644
> --- a/arch/arm/boot/dts/omap3-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-tobi.dts
> @@ -17,7 +17,7 @@
>  
>  / {
>   model = "TI OMAP3 Gumstix Overo on Tobi";
> - compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", 
> "ti,omap3";
> + compatible = "gumstix,omap3-tobi", "gumstix,omap3-overo", 
> "ti,omap36xx", "ti,omap3";
>  
>   leds {
>   compatible = "gpio-leds";
> 


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/4] ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi

2014-02-13 Thread Nishanth Menon
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Unfortunatly the device tree for older OMAP35xx Overo cannot be used
> with newer OMAP36xx and vice-versa. To address this issue, move most of
> the Tobi DTS to a common include file, and create model-specific Tobi
> DTS.
> 
> Signed-off-by: Florian Vaussard 
> Tested-by: Kevin Hilman 
Acked-by: Nishanth Menon 
> ---
>  arch/arm/boot/dts/Makefile |  3 ++-
>  arch/arm/boot/dts/omap3-overo-storm-tobi.dts   | 22 
> ++
>  ...omap3-tobi.dts => omap3-overo-tobi-common.dtsi} |  6 --
>  arch/arm/boot/dts/omap3-overo-tobi.dts | 22 
> ++
>  4 files changed, 46 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/boot/dts/omap3-overo-storm-tobi.dts
>  rename arch/arm/boot/dts/{omap3-tobi.dts => omap3-overo-tobi-common.dtsi} 
> (91%)
>  create mode 100644 arch/arm/boot/dts/omap3-overo-tobi.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b9d6a8b..e8355f4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -208,7 +208,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>   omap3-n900.dtb \
>   omap3-n9.dtb \
>   omap3-n950.dtb \
> - omap3-tobi.dtb \
> + omap3-overo-tobi.dtb \
> + omap3-overo-storm-tobi.dtb \
>   omap3-gta04.dtb \
>   omap3-igep0020.dtb \
>   omap3-igep0030.dtb \
> diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts 
> b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> new file mode 100644
> index 000..966b5c9
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
> + *
> + * 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.
> + */
> +
> +/*
> + * Tobi expansion board is manufactured by Gumstix Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include "omap36xx.dtsi"
> +#include "omap3-overo-tobi-common.dtsi"
> +
> +/ {
> + model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Tobi";
> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", 
> "ti,omap36xx", "ti,omap3";
> +};
> +
> diff --git a/arch/arm/boot/dts/omap3-tobi.dts 
> b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
> similarity index 91%
> rename from arch/arm/boot/dts/omap3-tobi.dts
> rename to arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
> index c742afa..4edc013 100644
> --- a/arch/arm/boot/dts/omap3-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
> @@ -10,15 +10,9 @@
>   * Tobi expansion board is manufactured by Gumstix Inc.
>   */
>  
> -/dts-v1/;
> -
> -#include "omap36xx.dtsi"
>  #include "omap3-overo.dtsi"
>  
>  / {
> - model = "TI OMAP3 Gumstix Overo on Tobi";
> - compatible = "gumstix,omap3-tobi", "gumstix,omap3-overo", 
> "ti,omap36xx", "ti,omap3";
> -
>   leds {
>   compatible = "gpio-leds";
>   heartbeat {
> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts 
> b/arch/arm/boot/dts/omap3-overo-tobi.dts
> new file mode 100644
> index 000..de5653e
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
> + *
> + * 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.
> + */
> +
> +/*
> + * Tobi expansion board is manufactured by Gumstix Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include "omap34xx.dtsi"
> +#include "omap3-overo-tobi-common.dtsi"
> +
> +/ {
> + model = "OMAP35xx Gumstix Overo on Tobi";
> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", 
> "ti,omap3430", "ti,omap3";
> +};
> +
> 


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] ARM: dts: omap3-tobi: Fix boot with OMAP36xx-based Overo

2014-02-13 Thread Nishanth Menon
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
> Tobi expansion board can be used with both OMAP35xx-based Overo,
> and OMAP36xx-based Overo. Currently the boot is broken with newer
> OMAP36xx-based Overo (Storm and alike). Fix include file and
> compatible string to be able to boot newer models.
> 
> This will break older models. This will be addressed later.
> 
> Signed-off-by: Tony Lindgren 
> Signed-off-by: Florian Vaussard 
> Tested-by: Kevin Hilman 

Acked-by: Nishanth Menon 
> ---
>  arch/arm/boot/dts/omap3-overo.dtsi | 3 ---
>  arch/arm/boot/dts/omap3-tobi.dts   | 5 -
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
> b/arch/arm/boot/dts/omap3-overo.dtsi
> index a461d2f..5970999 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -9,9 +9,6 @@
>  /*
>   * The Gumstix Overo must be combined with an expansion board.
>   */
> -/dts-v1/;
> -
> -#include "omap34xx.dtsi"
>  
>  / {
>   pwmleds {
> diff --git a/arch/arm/boot/dts/omap3-tobi.dts 
> b/arch/arm/boot/dts/omap3-tobi.dts
> index 7e4ad2a..0e3b8bf 100644
> --- a/arch/arm/boot/dts/omap3-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-tobi.dts
> @@ -10,11 +10,14 @@
>   * Tobi expansion board is manufactured by Gumstix Inc.
>   */
>  
> +/dts-v1/;
> +
> +#include "omap36xx.dtsi"
>  #include "omap3-overo.dtsi"
>  
>  / {
>   model = "TI OMAP3 Gumstix Overo on Tobi";
> - compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3";
> + compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", 
> "ti,omap3";
>  
>   leds {
>   compatible = "gpio-leds";
> 


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/8] OMAP: OMAP3 DSS related clock patches

2014-02-13 Thread Belisko Marek
On Thu, Feb 13, 2014 at 11:03 AM, Tomi Valkeinen  wrote:
> Hi,
>
> I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have
> them all fixed with this series. This fixes the problems for both non-DT boot,
> but also for DT boot with DSS DT support (which is not merged yet).
>
> The non-DT boot related fixes should be merged for 3.14, but I'd like the DT
> boot related fixes to be merged for 3.14 also, as that'll make handling the 
> DSS
> DT support easier.
>
> This is based on v3.14-rc2.
Tested on gta04 board with DSS DT patches v3 (rebased on 3.14-rc2).
Panel is finally working fine.
Thanks.

Tested-by: Marek Belisko 

>
>  Tomi
>
> Tomi Valkeinen (8):
>   clk: divider: fix rate calculation for fractional rates
>   clk: ti/divider: fix rate calculation for fractional rates
>   ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
>   ARM: dts: fix omap3 dss clock handle names
>   ARM: dts: fix DPLL4 x2 clkouts on 3630
>   ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck
>   ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path
>   OMAPDSS: fix rounding when calculating fclk rate
>
>  arch/arm/boot/dts/omap3430es1-clocks.dtsi  |  6 +--
>  .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi|  6 +--
>  arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 +++
>  arch/arm/boot/dts/omap36xx.dtsi|  2 +-
>  arch/arm/boot/dts/omap3xxx-clocks.dtsi |  8 +--
>  arch/arm/mach-omap2/cclock3xxx_data.c  |  2 +
>  arch/arm/mach-omap2/dpll3xxx.c | 62 
> ++
>  drivers/clk/clk-divider.c  | 10 ++--
>  drivers/clk/ti/divider.c   |  8 +--
>  drivers/video/omap2/dss/dss.c  |  4 +-
>  include/linux/clk/ti.h |  4 ++
>  11 files changed, 111 insertions(+), 21 deletions(-)
>
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/8] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

2014-02-13 Thread Tomi Valkeinen
On 13/02/14 12:04, Tomi Valkeinen wrote:
> If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
> clk_set_rate() on the clock "skips" the x2 multiplier as there are no
> set_rate and round_rate functions defined for the clkoutx2.
> 
> This results in getting double the requested clock rates, breaking the
> display on omap3430 based devices.
> 
> This patch implements set_rate and round_rate for clkoutx2.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  arch/arm/mach-omap2/cclock3xxx_data.c |  2 ++
>  arch/arm/mach-omap2/dpll3xxx.c| 62 
> +++
>  include/linux/clk/ti.h|  4 +++
>  3 files changed, 68 insertions(+)

Argh. This patch 3/8 was an old version, and not valid. It does not work for
omap3430. I had earlier posted a proper version, but somehow I managed to get
an old version for this series.

The correct version can be found from

http://mid.gmane.org/1391080640-23370-1-git-send-email-tomi.valkei...@ti.com

and I'll also include it below.

 Tomi

From 0d46054a8b33bc1f7a37bc9b17dd1631b1a06047 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Thu, 30 Jan 2014 13:17:20 +0200
Subject: [PATCH] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
clk_set_rate() on the clock "skips" the x2 multiplier as there are no
set_rate and round_rate functions defined for the clkoutx2.

This results in getting double the requested clock rates, breaking the
display on omap3430 based devices. This got broken when
d0f58bd3bba3877fb1af4664c4e33273d36f00e4 and related patches were merged
for v3.14, as omapdss driver now relies more on the clk-framework and
CLK_SET_RATE_PARENT.

This patch implements set_rate and round_rate for clkoutx2.

Tested on OMAP3430, OMAP3630, OMAP4460.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/cclock3xxx_data.c |  2 +
 arch/arm/mach-omap2/dpll3xxx.c| 92 +--
 include/linux/clk/ti.h|  4 ++
 3 files changed, 83 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..11ed9152e665 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
.enable = &omap2_dflt_clk_enable,
.disable= &omap2_dflt_clk_disable,
.is_enabled = &omap2_dflt_clk_is_enabled,
+   .set_rate   = &omap3_clkoutx2_set_rate,
.recalc_rate= &omap3_clkoutx2_recalc,
+   .round_rate = &omap3_clkoutx2_round_rate,
 };
 
 static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced807c9..3c418ea54bbe 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -623,6 +623,32 @@ void omap3_dpll_deny_idle(struct clk_hw_omap *clk)
 
 /* Clock control for DPLL outputs */
 
+/* Find the parent DPLL for the given clkoutx2 clock */
+static struct clk_hw_omap *omap3_find_clkoutx2_dpll(struct clk_hw *hw)
+{
+   struct clk_hw_omap *pclk = NULL;
+   struct clk *parent;
+
+   /* Walk up the parents of clk, looking for a DPLL */
+   do {
+   do {
+   parent = __clk_get_parent(hw->clk);
+   hw = __clk_get_hw(parent);
+   } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
+   if (!hw)
+   break;
+   pclk = to_clk_hw_omap(hw);
+   } while (pclk && !pclk->dpll_data);
+
+   /* clk does not have a DPLL as a parent?  error in the clock data */
+   if (!pclk) {
+   WARN_ON(1);
+   return NULL;
+   }
+
+   return pclk;
+}
+
 /**
  * omap3_clkoutx2_recalc - recalculate DPLL X2 output virtual clock rate
  * @clk: DPLL output struct clk
@@ -637,27 +663,14 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
unsigned long rate;
u32 v;
struct clk_hw_omap *pclk = NULL;
-   struct clk *parent;
 
if (!parent_rate)
return 0;
 
-   /* Walk up the parents of clk, looking for a DPLL */
-   do {
-   do {
-   parent = __clk_get_parent(hw->clk);
-   hw = __clk_get_hw(parent);
-   } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
-   if (!hw)
-   break;
-   pclk = to_clk_hw_omap(hw);
-   } while (pclk && !pclk->dpll_data);
+   pclk = omap3_find_clkoutx2_dpll(hw);
 
-   /* clk does not have a DPLL as a parent?  error in the clock data */
-   if (!pclk) {
-   WARN_ON(1);
+   if (!pclk)
return 0;
-   }
 
dd = pclk->dpll_data;
 
@@ -672,6 +685,55 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
retur

[PATCH v2 3/4] ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi

2014-02-13 Thread Florian Vaussard
Unfortunatly the device tree for older OMAP35xx Overo cannot be used
with newer OMAP36xx and vice-versa. To address this issue, move most of
the Tobi DTS to a common include file, and create model-specific Tobi
DTS.

Signed-off-by: Florian Vaussard 
Tested-by: Kevin Hilman 
---
 arch/arm/boot/dts/Makefile |  3 ++-
 arch/arm/boot/dts/omap3-overo-storm-tobi.dts   | 22 ++
 ...omap3-tobi.dts => omap3-overo-tobi-common.dtsi} |  6 --
 arch/arm/boot/dts/omap3-overo-tobi.dts | 22 ++
 4 files changed, 46 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-tobi.dts
 rename arch/arm/boot/dts/{omap3-tobi.dts => omap3-overo-tobi-common.dtsi} (91%)
 create mode 100644 arch/arm/boot/dts/omap3-overo-tobi.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b..e8355f4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -208,7 +208,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-n900.dtb \
omap3-n9.dtb \
omap3-n950.dtb \
-   omap3-tobi.dtb \
+   omap3-overo-tobi.dtb \
+   omap3-overo-storm-tobi.dtb \
omap3-gta04.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts 
b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
new file mode 100644
index 000..966b5c9
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
+ *
+ * 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.
+ */
+
+/*
+ * Tobi expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include "omap36xx.dtsi"
+#include "omap3-overo-tobi-common.dtsi"
+
+/ {
+   model = "OMAP36xx/AM37xx/DM37xx Gumstix Overo on Tobi";
+   compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", 
"ti,omap36xx", "ti,omap3";
+};
+
diff --git a/arch/arm/boot/dts/omap3-tobi.dts 
b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
similarity index 91%
rename from arch/arm/boot/dts/omap3-tobi.dts
rename to arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
index c742afa..4edc013 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
@@ -10,15 +10,9 @@
  * Tobi expansion board is manufactured by Gumstix Inc.
  */
 
-/dts-v1/;
-
-#include "omap36xx.dtsi"
 #include "omap3-overo.dtsi"
 
 / {
-   model = "TI OMAP3 Gumstix Overo on Tobi";
-   compatible = "gumstix,omap3-tobi", "gumstix,omap3-overo", 
"ti,omap36xx", "ti,omap3";
-
leds {
compatible = "gpio-leds";
heartbeat {
diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts 
b/arch/arm/boot/dts/omap3-overo-tobi.dts
new file mode 100644
index 000..de5653e
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
+ *
+ * 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.
+ */
+
+/*
+ * Tobi expansion board is manufactured by Gumstix Inc.
+ */
+
+/dts-v1/;
+
+#include "omap34xx.dtsi"
+#include "omap3-overo-tobi-common.dtsi"
+
+/ {
+   model = "OMAP35xx Gumstix Overo on Tobi";
+   compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", 
"ti,omap3430", "ti,omap3";
+};
+
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/4] ARM: dts: omap3-tobi: Use the correct vendor prefix

2014-02-13 Thread Florian Vaussard
Gumstix is the correct vendor for all Overo related products.

Reported-by: Javier Martinez Canillas 
Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap3-tobi.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index 0e3b8bf..c742afa 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -17,7 +17,7 @@
 
 / {
model = "TI OMAP3 Gumstix Overo on Tobi";
-   compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", 
"ti,omap3";
+   compatible = "gumstix,omap3-tobi", "gumstix,omap3-overo", 
"ti,omap36xx", "ti,omap3";
 
leds {
compatible = "gpio-leds";
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 4/4] Documentation: dt: OMAP: Update Overo/Tobi

2014-02-13 Thread Florian Vaussard
Update the compatible string for Overo/Tobi to reflect the latest
changes.

Signed-off-by: Florian Vaussard 
---
 Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 34dc40c..af9b4a0 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -91,7 +91,7 @@ Boards:
   compatible = "ti,omap3-beagle", "ti,omap3"
 
 - OMAP3 Tobi with Overo : Commercial expansion board with daughter board
-  compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
+  compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
 
 - OMAP4 SDP : Software Development Board
   compatible = "ti,omap4-sdp", "ti,omap4430"
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/4] ARM: dts: omap3-tobi: Fix boot with OMAP36xx-based Overo

2014-02-13 Thread Florian Vaussard
Tobi expansion board can be used with both OMAP35xx-based Overo,
and OMAP36xx-based Overo. Currently the boot is broken with newer
OMAP36xx-based Overo (Storm and alike). Fix include file and
compatible string to be able to boot newer models.

This will break older models. This will be addressed later.

Signed-off-by: Tony Lindgren 
Signed-off-by: Florian Vaussard 
Tested-by: Kevin Hilman 
---
 arch/arm/boot/dts/omap3-overo.dtsi | 3 ---
 arch/arm/boot/dts/omap3-tobi.dts   | 5 -
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index a461d2f..5970999 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -9,9 +9,6 @@
 /*
  * The Gumstix Overo must be combined with an expansion board.
  */
-/dts-v1/;
-
-#include "omap34xx.dtsi"
 
 / {
pwmleds {
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index 7e4ad2a..0e3b8bf 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -10,11 +10,14 @@
  * Tobi expansion board is manufactured by Gumstix Inc.
  */
 
+/dts-v1/;
+
+#include "omap36xx.dtsi"
 #include "omap3-overo.dtsi"
 
 / {
model = "TI OMAP3 Gumstix Overo on Tobi";
-   compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3";
+   compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap36xx", 
"ti,omap3";
 
leds {
compatible = "gpio-leds";
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/4] ARM: dts: Fixes for Overo/Tobi against 3.14-rc2

2014-02-13 Thread Florian Vaussard
OMAP36xx-based Overo (Storm and alike) are now failing to boot with 3.14-rc2 
[1].
This series fixes this, by moving model-agnostic DT into a common dtsi file,
and creating model-specific DT files:

- omap3-overo-tobi.dts -> older OMAP35xx Overo
- omap3-overo-storm-tobi.dts -> newer OMAP36xx/AM37xx/DM37xx Overo

People will have to use the right Overo / expansion board combination.

(Patch 2 in an unrelated fix that was waiting in my queue.)

omap3-overo-tobi.dts tested with Overo Sand (OMAP3503) and 
omap3-overo-storm-tobi.dts
tested with Overo EarthStorm (AM3703). Both boot. With the Overo Sand, I cannot
mount the ext3 rootfs, but this seems unrelated to the current topic, maybe
a missing errata.

Regards,
Florian

Changes since v1:
- Add "ti,omap3430" as a compatible string for OMAP35xx-based Overo
- Update the DT documentation to silence out checkpatch warnings (patch 4)

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110006

Florian Vaussard (4):
  ARM: dts: omap3-tobi: Fix boot with OMAP36xx-based Overo
  ARM: dts: omap3-tobi: Use the correct vendor prefix
  ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi
  Documentation: dt: OMAP: Update Overo/Tobi

 .../devicetree/bindings/arm/omap/omap.txt  |  2 +-
 arch/arm/boot/dts/Makefile |  3 ++-
 arch/arm/boot/dts/omap3-overo-storm-tobi.dts   | 22 ++
 ...omap3-tobi.dts => omap3-overo-tobi-common.dtsi} |  3 ---
 arch/arm/boot/dts/omap3-overo-tobi.dts | 22 ++
 arch/arm/boot/dts/omap3-overo.dtsi |  3 ---
 6 files changed, 47 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-overo-storm-tobi.dts
 rename arch/arm/boot/dts/{omap3-tobi.dts => omap3-overo-tobi-common.dtsi} (94%)
 create mode 100644 arch/arm/boot/dts/omap3-overo-tobi.dts

-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: OMAP: clock DT conversion issues with omap36xx

2014-02-13 Thread Tomi Valkeinen
On 13/02/14 11:03, Tomi Valkeinen wrote:
> On 12/02/14 15:18, Tomi Valkeinen wrote:
> 
>> However, I hacked together the patch below, which "fixes" the issue for
>> 96m and dss fclk. It sets the clock parents so that the x2 clocks are
>> skipped, and makes the x2 clock nodes compatible with "unused", making
>> them effectively disappear. I only verified dss fclk, so Christoph, can
>> you verify the 96m clock?
> 
> Aaand the hack patch I sent is crap... We can't skip the x2 clock path,
> as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is
> present on 3630 also.
> 
> I think the best and simplest way to fix this is by setting the
> multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I
> didn't think of it yesterday.
> 
> I have a bunch of other patches needed to get the clocks right, so I'll
> send a series separately a bit later today.

I just sent the "OMAP: OMAP3 DSS related clock patches" series to l-o
and arm lists, which hopefully solves issues discussed in this thread.

 Tomi




signature.asc
Description: OpenPGP digital signature


[PATCH 7/8] ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path

2014-02-13 Thread Tomi Valkeinen
Set 'ti,set-rate-parent' property for clocks in the dpll4_m4 clock
path, which is used for DSS functional clock. This fixes DSS driver's
clock rate configuration, which needs the rate to be propagated properly
to the divider node (dpll4_m4_ck).

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi 
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index df3c699a1893..12be2b35dae9 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -429,6 +429,7 @@
clocks = <&dpll4_m4_ck>;
ti,clock-mult = <2>;
ti,clock-div = <1>;
+   ti,set-rate-parent;
};
 
dpll4_m4x2_ck: dpll4_m4x2_ck {
@@ -438,6 +439,7 @@
ti,bit-shift = <0x1d>;
reg = <0x0d00>;
ti,set-bit-to-disable;
+   ti,set-rate-parent;
};
 
dpll4_m5_ck: dpll4_m5_ck {
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 8/8] OMAPDSS: fix rounding when calculating fclk rate

2014-02-13 Thread Tomi Valkeinen
"clk: divider: fix rate calculation for fractional rates" patch (and
similar for TI specific divider) fixes the clk-divider's rounding. This
patch updates the DSS driver to round the rates accordingly.

This fixes the DSS's warnings about clock rate mismatch, and also fixes
the wrong fclk rate being set.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9a145da35ad3..efe7c308341d 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -471,7 +471,7 @@ bool dss_div_calc(unsigned long pck, unsigned long fck_min,
fckd_stop = max(DIV_ROUND_UP(prate * m, fck_hw_max), 1ul);
 
for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
-   fck = prate / fckd * m;
+   fck = DIV_ROUND_UP(prate, fckd) * m;
 
if (func(fck, data))
return true;
@@ -520,7 +520,7 @@ static int dss_setup_default_clock(void)
 
fck_div = DIV_ROUND_UP(prate * dss.feat->dss_fck_multiplier,
max_dss_fck);
-   fck = prate / fck_div * dss.feat->dss_fck_multiplier;
+   fck = DIV_ROUND_UP(prate, fck_div) * 
dss.feat->dss_fck_multiplier;
}
 
r = dss_set_fck_rate(fck);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/8] clk: divider: fix rate calculation for fractional rates

2014-02-13 Thread Tomi Valkeinen
clk-divider.c does not calculate the rates consistently at the moment.

As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:

6: 14400
7: 123428571.428571...
8: 10800

Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:

14400 -> 14400
14399 -> 123428571
123428572 -> 123428571
123428571 -> 10800

Note how clk_round_rate() returns 123428571 for rates from 123428572 to
14399, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 10800.

This means that the following code works a bit oddly:

rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);

As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 10800, not 123428571 returned by the
clk_round_rate.

This patch changes the clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:

14400 -> 14400
14399 -> 123428572
123428572 -> 123428572
123428571 -> 10800

Signed-off-by: Tomi Valkeinen 
Cc: Mike Turquette 
---
 drivers/clk/clk-divider.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -24,7 +24,7 @@
  * Traits of this clock:
  * prepare - clk_prepare only ensures that parents are prepared
  * enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable.  clk->rate = parent->rate / divisor
+ * rate - rate is adjustable.  clk->rate = DIV_ROUND_UP(parent->rate / divisor)
  * parent - fixed parent.  No clk_set_parent support
  */
 
@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw 
*hw,
return parent_rate;
}
 
-   return parent_rate / div;
+   return DIV_ROUND_UP(parent_rate, div);
 }
 
 /*
@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned 
long rate,
}
parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
MULT_ROUND_UP(rate, i));
-   now = parent_rate / i;
+   now = DIV_ROUND_UP(parent_rate, i);
if (now <= rate && now > best) {
bestdiv = i;
best = now;
@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, 
unsigned long rate,
int div;
div = clk_divider_bestdiv(hw, rate, prate);
 
-   return *prate / div;
+   return DIV_ROUND_UP(*prate, div);
 }
 
 static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned 
long rate,
unsigned long flags = 0;
u32 val;
 
-   div = parent_rate / rate;
+   div = DIV_ROUND_UP(parent_rate, rate);
value = _get_val(divider, div);
 
if (value > div_mask(divider))
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/8] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT

2014-02-13 Thread Tomi Valkeinen
If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
clk_set_rate() on the clock "skips" the x2 multiplier as there are no
set_rate and round_rate functions defined for the clkoutx2.

This results in getting double the requested clock rates, breaking the
display on omap3430 based devices.

This patch implements set_rate and round_rate for clkoutx2.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/cclock3xxx_data.c |  2 ++
 arch/arm/mach-omap2/dpll3xxx.c| 62 +++
 include/linux/clk/ti.h|  4 +++
 3 files changed, 68 insertions(+)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..11ed9152e665 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
.enable = &omap2_dflt_clk_enable,
.disable= &omap2_dflt_clk_disable,
.is_enabled = &omap2_dflt_clk_is_enabled,
+   .set_rate   = &omap3_clkoutx2_set_rate,
.recalc_rate= &omap3_clkoutx2_recalc,
+   .round_rate = &omap3_clkoutx2_round_rate,
 };
 
 static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3185ced807c9..4ba7e90e127b 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -672,6 +672,68 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
return rate;
 }
 
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *prate)
+{
+   const struct dpll_data *dd;
+   u32 v;
+   struct clk_hw_omap *pclk = NULL;
+   struct clk *parent;
+
+   if (!*prate)
+   return 0;
+
+   /* Walk up the parents of clk, looking for a DPLL */
+   do {
+   do {
+   parent = __clk_get_parent(hw->clk);
+   hw = __clk_get_hw(parent);
+   } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
+   if (!hw)
+   break;
+   pclk = to_clk_hw_omap(hw);
+   } while (pclk && !pclk->dpll_data);
+
+   /* clk does not have a DPLL as a parent?  error in the clock data */
+   if (!pclk) {
+   WARN_ON(1);
+   return 0;
+   }
+
+   dd = pclk->dpll_data;
+
+   /* TYPE J does not have a clkoutx2 */
+   if (dd->flags & DPLL_J_TYPE) {
+   *prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
+   return *prate;
+   }
+
+   WARN_ON(!dd->enable_mask);
+
+   v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
+   v >>= __ffs(dd->enable_mask);
+
+   /* If in bypass, the rate is fixed to the bypass rate*/
+   if (v != OMAP3XXX_EN_DPLL_LOCKED)
+   return *prate;
+
+   if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+   unsigned long best_parent;
+
+   best_parent = (rate / 2);
+   *prate = __clk_round_rate(__clk_get_parent(hw->clk),
+   best_parent);
+   }
+
+   return *prate * 2;
+}
+
 /* OMAP3/4 non-CORE DPLL clkops */
 const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
.allow_idle = omap3_dpll_allow_idle,
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..4a21a872dbbd 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -245,6 +245,10 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned 
long target_rate,
 void omap2_init_clk_clkdm(struct clk_hw *clk);
 unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
unsigned long parent_rate);
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *prate);
 int omap2_clkops_enable_clkdm(struct clk_hw *hw);
 void omap2_clkops_disable_clkdm(struct clk_hw *hw);
 int omap2_clk_disable_autoidle_all(void);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/8] ARM: dts: fix omap3 dss clock handle names

2014-02-13 Thread Tomi Valkeinen
The DSS fclk and iclk handles are named differently on OMAP3430 ES1 than
on later OMAP revisions. The ES1 has handles 'dss1_alwon_fck_3430es1'
and 'dss_ick_3430es1', whereas later revisions have similar names but
ending with 'es2'.

This means we don't have one clock handle to which we could refer to
when defining the DSS clocks.

However, as the namespaces are separate for ES1 and ES2+ OMAPs, we can
just rename the handles to 'dss1_alwon_fck' and 'dss_ick' for both ES1
and ES2+, removing the issue.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/boot/dts/omap3430es1-clocks.dtsi | 6 +++---
 arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi 
b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
index 02f6c7fabbec..f9202656168f 100644
--- a/arch/arm/boot/dts/omap3430es1-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
@@ -152,7 +152,7 @@
clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>;
};
 
-   dss1_alwon_fck_3430es1: dss1_alwon_fck_3430es1 {
+   dss1_alwon_fck: dss1_alwon_fck_3430es1 {
#clock-cells = <0>;
compatible = "ti,gate-clock";
clocks = <&dpll4_m4x2_ck>;
@@ -161,7 +161,7 @@
ti,set-rate-parent;
};
 
-   dss_ick_3430es1: dss_ick_3430es1 {
+   dss_ick: dss_ick_3430es1 {
#clock-cells = <0>;
compatible = "ti,omap3-no-wait-interface-clock";
clocks = <&l4_ick>;
@@ -184,7 +184,7 @@
dss_clkdm: dss_clkdm {
compatible = "ti,clockdomain";
clocks = <&dss_tv_fck>, <&dss_96m_fck>, <&dss2_alwon_fck>,
-<&dss1_alwon_fck_3430es1>, <&dss_ick_3430es1>;
+<&dss1_alwon_fck>, <&dss_ick>;
};
 
d2d_clkdm: d2d_clkdm {
diff --git a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi 
b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
index af9ae5346bf2..080fb3f4e429 100644
--- a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
@@ -160,7 +160,7 @@
ti,bit-shift = <30>;
};
 
-   dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2 {
+   dss1_alwon_fck: dss1_alwon_fck_3430es2 {
#clock-cells = <0>;
compatible = "ti,dss-gate-clock";
clocks = <&dpll4_m4x2_ck>;
@@ -169,7 +169,7 @@
ti,set-rate-parent;
};
 
-   dss_ick_3430es2: dss_ick_3430es2 {
+   dss_ick: dss_ick_3430es2 {
#clock-cells = <0>;
compatible = "ti,omap3-dss-interface-clock";
clocks = <&l4_ick>;
@@ -216,7 +216,7 @@
dss_clkdm: dss_clkdm {
compatible = "ti,clockdomain";
clocks = <&dss_tv_fck>, <&dss_96m_fck>, <&dss2_alwon_fck>,
-<&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>;
+<&dss1_alwon_fck>, <&dss_ick>;
};
 
core_l4_clkdm: core_l4_clkdm {
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 6/8] ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck

2014-02-13 Thread Tomi Valkeinen
We need to use set-rate-parent for dpll4_m4 clock path, so use the
ti,fixed-factor-clock version which supports set-rate-parent property.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi 
b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 0b2df76b9d38..6b5280d04a0e 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -79,7 +79,7 @@
 };
 
 &dpll4_m4x2_mul_ck {
-   clock-mult = <1>;
+   ti,clock-mult = <1>;
 };
 
 &dpll4_m5x2_mul_ck {
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi 
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index cb04d4b37e7f..df3c699a1893 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -425,10 +425,10 @@
 
dpll4_m4x2_mul_ck: dpll4_m4x2_mul_ck {
#clock-cells = <0>;
-   compatible = "fixed-factor-clock";
+   compatible = "ti,fixed-factor-clock";
clocks = <&dpll4_m4_ck>;
-   clock-mult = <2>;
-   clock-div = <1>;
+   ti,clock-mult = <2>;
+   ti,clock-div = <1>;
};
 
dpll4_m4x2_ck: dpll4_m4x2_ck {
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/8] ARM: dts: fix DPLL4 x2 clkouts on 3630

2014-02-13 Thread Tomi Valkeinen
OMAP3630 DPLL4 is different than on OMAP3430, in that it doesn't have
the x2 multiplier for its outputs. This is not currently reflected in
the clock DT data.

Fix the issue by setting the clock multiplier to 1 (instead of 2) for the
DPLL4 output clocks.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 
 arch/arm/boot/dts/omap36xx.dtsi|  2 +-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi 
b/arch/arm/boot/dts/omap36xx-clocks.dtsi
index 2fcf253b677c..0b2df76b9d38 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -70,6 +70,26 @@
};
 };
 
+&dpll4_m2x2_mul_ck {
+   clock-mult = <1>;
+};
+
+&dpll4_m3x2_mul_ck {
+   clock-mult = <1>;
+};
+
+&dpll4_m4x2_mul_ck {
+   clock-mult = <1>;
+};
+
+&dpll4_m5x2_mul_ck {
+   clock-mult = <1>;
+};
+
+&dpll4_m6x2_mul_ck {
+   clock-mult = <1>;
+};
+
 &cm_clockdomains {
dpll4_clkdm: dpll4_clkdm {
compatible = "ti,clockdomain";
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 7e8dee9175d6..5e1bcd06a996 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -52,7 +52,7 @@
};
 };
 
-/include/ "omap36xx-clocks.dtsi"
 /include/ "omap34xx-omap36xx-clocks.dtsi"
 /include/ "omap36xx-omap3430es2plus-clocks.dtsi"
 /include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
+/include/ "omap36xx-clocks.dtsi"
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/8] clk: ti/divider: fix rate calculation for fractional rates

2014-02-13 Thread Tomi Valkeinen
ti/clk-divider.c does not calculate the rates consistently at the moment.

As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:

6: 14400
7: 123428571.428571...
8: 10800

Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:

14400 -> 14400
14399 -> 123428571
123428572 -> 123428571
123428571 -> 10800

Note how clk_round_rate() returns 123428571 for rates from 123428572 to
14399, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 10800.

This means that the following code works a bit oddly:

rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);

As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 10800, not 123428571 returned by the
clk_round_rate.

This patch changes the ti/clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:

14400 -> 14400
14399 -> 123428572
123428572 -> 123428572
123428571 -> 10800

Signed-off-by: Tomi Valkeinen 
---
 drivers/clk/ti/divider.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index a15e445570b2..e6aa10db7bba 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -112,7 +112,7 @@ static unsigned long ti_clk_divider_recalc_rate(struct 
clk_hw *hw,
return parent_rate;
}
 
-   return parent_rate / div;
+   return DIV_ROUND_UP(parent_rate, div);
 }
 
 /*
@@ -182,7 +182,7 @@ static int ti_clk_divider_bestdiv(struct clk_hw *hw, 
unsigned long rate,
}
parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
MULT_ROUND_UP(rate, i));
-   now = parent_rate / i;
+   now = DIV_ROUND_UP(parent_rate, i);
if (now <= rate && now > best) {
bestdiv = i;
best = now;
@@ -205,7 +205,7 @@ static long ti_clk_divider_round_rate(struct clk_hw *hw, 
unsigned long rate,
int div;
div = ti_clk_divider_bestdiv(hw, rate, prate);
 
-   return *prate / div;
+   return DIV_ROUND_UP(*prate, div);
 }
 
 static int ti_clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -216,7 +216,7 @@ static int ti_clk_divider_set_rate(struct clk_hw *hw, 
unsigned long rate,
unsigned long flags = 0;
u32 val;
 
-   div = parent_rate / rate;
+   div = DIV_ROUND_UP(parent_rate, rate);
value = _get_val(divider, div);
 
if (value > div_mask(divider))
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/8] OMAP: OMAP3 DSS related clock patches

2014-02-13 Thread Tomi Valkeinen
Hi,

I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have
them all fixed with this series. This fixes the problems for both non-DT boot,
but also for DT boot with DSS DT support (which is not merged yet).

The non-DT boot related fixes should be merged for 3.14, but I'd like the DT
boot related fixes to be merged for 3.14 also, as that'll make handling the DSS
DT support easier.

This is based on v3.14-rc2.

 Tomi

Tomi Valkeinen (8):
  clk: divider: fix rate calculation for fractional rates
  clk: ti/divider: fix rate calculation for fractional rates
  ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
  ARM: dts: fix omap3 dss clock handle names
  ARM: dts: fix DPLL4 x2 clkouts on 3630
  ARM: dts: use ti,fixed-factor-clock for dpll4_m4x2_mul_ck
  ARM: dts: set 'ti,set-rate-parent' for dpll4_m4 path
  OMAPDSS: fix rounding when calculating fclk rate

 arch/arm/boot/dts/omap3430es1-clocks.dtsi  |  6 +--
 .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi|  6 +--
 arch/arm/boot/dts/omap36xx-clocks.dtsi | 20 +++
 arch/arm/boot/dts/omap36xx.dtsi|  2 +-
 arch/arm/boot/dts/omap3xxx-clocks.dtsi |  8 +--
 arch/arm/mach-omap2/cclock3xxx_data.c  |  2 +
 arch/arm/mach-omap2/dpll3xxx.c | 62 ++
 drivers/clk/clk-divider.c  | 10 ++--
 drivers/clk/ti/divider.c   |  8 +--
 drivers/video/omap2/dss/dss.c  |  4 +-
 include/linux/clk/ti.h |  4 ++
 11 files changed, 111 insertions(+), 21 deletions(-)

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] serial: omap-serial: Move info message to probe function

2014-02-13 Thread Uwe Kleine-König
On Fri, Jan 24, 2014 at 06:09:41PM +0100, Markus Pargmann wrote:
> Currently the info message about a missing wakeirq for uart is printed
> every time the serial driver's startup function is called. This happens
> multiple times and not just once.
> 
> This patch moves the infomessage to the probe function to display it
> only once.
> 
> Cc: Tony Lindgren 
> Signed-off-by: Markus Pargmann 
Acked-by: Uwe Kleine-König 
> ---
>  drivers/tty/serial/omap-serial.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/omap-serial.c 
> b/drivers/tty/serial/omap-serial.c
> index fa511eb..2051581 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -738,9 +738,6 @@ static int serial_omap_startup(struct uart_port *port)
>   return retval;
>   }
>   disable_irq(up->wakeirq);
> - } else {
> - dev_info(up->port.dev, "no wakeirq for uart%d\n",
> -  up->port.line);
>   }
>  
>   dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->port.line);
> @@ -1687,6 +1684,9 @@ static int serial_omap_probe(struct platform_device 
> *pdev)
>   up->port.iotype = UPIO_MEM;
>   up->port.irq = uartirq;
>   up->wakeirq = wakeirq;
> + if (!up->wakeirq)
> + dev_info(up->port.dev, "no wakeirq for uart%d\n",
> +  up->port.line);
>  
>   up->port.regshift = 2;
>   up->port.fifosize = 64;
> -- 
> 1.8.5.2
> 
> 

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP: clock DT conversion issues with omap36xx

2014-02-13 Thread Tomi Valkeinen
On 12/02/14 15:18, Tomi Valkeinen wrote:

> However, I hacked together the patch below, which "fixes" the issue for
> 96m and dss fclk. It sets the clock parents so that the x2 clocks are
> skipped, and makes the x2 clock nodes compatible with "unused", making
> them effectively disappear. I only verified dss fclk, so Christoph, can
> you verify the 96m clock?

Aaand the hack patch I sent is crap... We can't skip the x2 clock path,
as the dpll4_mNx2_ck clock nodes handle enable/disable bit, which is
present on 3630 also.

I think the best and simplest way to fix this is by setting the
multiplier in the dpll4_mNx2_mul_ck nodes to 1. I don't know why I
didn't think of it yesterday.

I have a bunch of other patches needed to get the clocks right, so I'll
send a series separately a bit later today.

 Tomi




signature.asc
Description: OpenPGP digital signature


[PATCH 3/4] clk: ti: add support for default-rate property from DT

2014-02-13 Thread Tero Kristo
default-rate property can now be used to define default rates for clocks,
which get configured during boot.

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/prm_common.c |2 ++
 drivers/clk/ti/clk.c |1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index b4c4ab9..4703545 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -528,5 +528,7 @@ int __init of_prcm_init(void)
 
ti_dt_clockdomains_setup();
 
+   of_clk_set_init_rates();
+
return 0;
 }
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index b1a6f71..23998b7 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -156,6 +156,7 @@ void ti_dt_clk_init_provider(struct device_node *parent, 
int index)
clk_init_cb = (of_clk_init_cb_t)match->data;
pr_debug("%s: initializing: %s\n", __func__, np->name);
clk_init_cb(np);
+   of_clk_parse_init_rate(np, NULL);
}
 
list_for_each_entry_safe(retry, tmp, &retry_list, link) {
-- 
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 0/4] clk: dt: add support for default rate/parent

2014-02-13 Thread Tero Kristo
Hi,

This set is a mix-match of new DT properties for generic and TI specific
clock drivers. Basically provided for commenting purposes. The patches
provide a way to configure clock parents / rates during boot through DT.

"default-rate" : sets rate of a clock during boot, supported for any DT
 clock type (through generic clock driver)
"ti,default-parent" : selects a default parent for a multiplexer clock,
  only supported for TI specific mux clock for now,
  as generic mux clock does not support DT clocks

Patch #4 provided as a reference how to move the default rates / parents
from kernel code to DT.

Default-rate logic in patch #2 looks somewhat complicated, as the clocks
need to be sorted based on their parents to avoid cases where a child clock
would set its rate first, just to be overridden by its parent changing
rate later and resulting in incorrect rate for the child clock.

If the default-rate generic property is not going to fly, it can be moved
to TI only drivers also.

-Tero

--
To unsubscribe from this list: send the line "unsubscribe 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] clk: ti: omap4: set default-parents and default-rates using DT

2014-02-13 Thread Tero Kristo
Setup dpll_usb_ck and dpll_abe_ck using DT properties instead of hardcoding
the parents and rates in kernel.

Signed-off-by: Tero Kristo 
---
 arch/arm/boot/dts/omap4.dtsi |   12 
 drivers/clk/ti/clk-44xx.c|   42 --
 2 files changed, 12 insertions(+), 42 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..282ce66 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -761,3 +761,15 @@
 };
 
 /include/ "omap44xx-clocks.dtsi"
+
+&dpll_usb_ck {
+   default-rate = <96000>;
+};
+
+&dpll_abe_ck {
+   default-rate = <98304000>;
+};
+
+&abe_dpll_refclk_mux_ck {
+   ti,default-parent = <&sys_32k_ck>;
+};
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index ae00218..bc14a49 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -16,21 +16,6 @@
 #include 
 #include 
 
-/*
- * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
- * "3.6.3.2.3 CM1_ABE Clock Generator" states that the "DPLL_ABE_X2_CLK
- * must be set to 196.608 MHz" and hence, the DPLL locked frequency is
- * half of this value.
- */
-#define OMAP4_DPLL_ABE_DEFFREQ 98304000
-
-/*
- * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
- * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
- * locked frequency for the USB DPLL is 960MHz.
- */
-#define OMAP4_DPLL_USB_DEFFREQ 96000
-
 static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, "extalt_clkin_ck", "extalt_clkin_ck"),
DT_CLK(NULL, "pad_clks_src_ck", "pad_clks_src_ck"),
@@ -281,36 +266,9 @@ static struct ti_dt_clk omap44xx_clks[] = {
 
 int __init omap4xxx_dt_clk_init(void)
 {
-   int rc;
-   struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck, *usb_dpll;
-
ti_dt_clocks_register(omap44xx_clks);
 
omap2_clk_disable_autoidle_all();
 
-   /*
-* Lock USB DPLL on OMAP4 devices so that the L3INIT power
-* domain can transition to retention state when not in use.
-*/
-   usb_dpll = clk_get_sys(NULL, "dpll_usb_ck");
-   rc = clk_set_rate(usb_dpll, OMAP4_DPLL_USB_DEFFREQ);
-   if (rc)
-   pr_err("%s: failed to configure USB DPLL!\n", __func__);
-
-   /*
-* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
-* state when turning the ABE clock domain. Workaround this by
-* locking the ABE DPLL on boot.
-* Lock the ABE DPLL in any case to avoid issues with audio.
-*/
-   abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_refclk_mux_ck");
-   sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
-   rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
-   abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
-   if (!rc)
-   rc = clk_set_rate(abe_dpll, OMAP4_DPLL_ABE_DEFFREQ);
-   if (rc)
-   pr_err("%s: failed to configure ABE DPLL!\n", __func__);
-
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


[PATCH 1/4] clk: ti: mux: add support for default-parenting

2014-02-13 Thread Tero Kristo
ti,mux-clock now supports ti,default-parent property, which can be used
to configure the default parent of the clock during boot. This property
can be added to board specific files, or under the clock data itself.

Signed-off-by: Tero Kristo 
---
 Documentation/devicetree/bindings/clock/ti/mux.txt |7 ++
 drivers/clk/ti/mux.c   |   24 ++--
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt 
b/Documentation/devicetree/bindings/clock/ti/mux.txt
index 2d0d170..4e291eb 100644
--- a/Documentation/devicetree/bindings/clock/ti/mux.txt
+++ b/Documentation/devicetree/bindings/clock/ti/mux.txt
@@ -48,6 +48,8 @@ Optional properties:
   zero
 - ti,set-rate-parent : clk_set_rate is propagated to parent clock,
   not supported by the composite-mux-clock subtype
+- ti,default-parent : configures mux parent during boot to be the provided
+  phandle clock
 
 Examples:
 
@@ -65,6 +67,7 @@ abe_dpll_bypass_clk_mux_ck: 
abe_dpll_bypass_clk_mux_ck@4a306108 {
clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
ti,bit-shift = <24>;
reg = <0x0108>;
+   ti,default-parent = <&sys_32k_ck>;
 };
 
 mcbsp5_mux_fck: mcbsp5_mux_fck {
@@ -74,3 +77,7 @@ mcbsp5_mux_fck: mcbsp5_mux_fck {
ti,bit-shift = <4>;
reg = <0x02d8>;
 };
+
+&mcbsp5_mux_fck {
+   ti,default-parent = <&mcbsp_clks>;
+};
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 0197a47..557a7ce 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -108,7 +108,8 @@ static struct clk *_register_mux(struct device *dev, const 
char *name,
 const char **parent_names, u8 num_parents,
 unsigned long flags, void __iomem *reg,
 u8 shift, u32 mask, u8 clk_mux_flags,
-u32 *table, spinlock_t *lock)
+u32 *table, int default_parent,
+spinlock_t *lock)
 {
struct clk_mux *mux;
struct clk *clk;
@@ -136,6 +137,9 @@ static struct clk *_register_mux(struct device *dev, const 
char *name,
mux->table = table;
mux->hw.init = &init;
 
+   if (default_parent >= 0)
+   ti_clk_mux_set_parent(&mux->hw, default_parent);
+
clk = clk_register(dev, &mux->hw);
 
if (IS_ERR(clk))
@@ -161,6 +165,8 @@ static void of_mux_clk_setup(struct device_node *node)
u32 mask = 0;
u32 shift = 0;
u32 flags = 0;
+   struct device_node *default_parent;
+   int default_parent_idx = -1;
 
num_parents = of_clk_get_parent_count(node);
if (num_parents < 2) {
@@ -174,6 +180,19 @@ static void of_mux_clk_setup(struct device_node *node)
for (i = 0; i < num_parents; i++)
parent_names[i] = of_clk_get_parent_name(node, i);
 
+   default_parent = of_parse_phandle(node, "ti,default-parent", 0);
+
+   if (default_parent) {
+   for (i = 0; i < num_parents; i++) {
+   struct device_node *tmp;
+   tmp = of_parse_phandle(node, "clocks", i);
+   if (tmp == default_parent) {
+   default_parent_idx = i;
+   break;
+   }
+   }
+   }
+
reg = ti_clk_get_reg_addr(node, 0);
 
if (!reg)
@@ -195,7 +214,8 @@ static void of_mux_clk_setup(struct device_node *node)
mask = (1 << fls(mask)) - 1;
 
clk = _register_mux(NULL, node->name, parent_names, num_parents, flags,
-   reg, shift, mask, clk_mux_flags, NULL, NULL);
+   reg, shift, mask, clk_mux_flags, NULL,
+   default_parent_idx, NULL);
 
if (!IS_ERR(clk))
of_clk_add_provider(node, of_clk_src_simple_get, clk);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] clk: add support for default-rate

2014-02-13 Thread Tero Kristo
default-rate property can now be used to set initial rates for clocks.
This is added by default for all clocks which get initialized through
of_clk_init().

Signed-off-by: Tero Kristo 
---
 .../devicetree/bindings/clock/clock-bindings.txt   |9 ++
 drivers/clk/clk.c  |   86 
 include/linux/clk-provider.h   |2 +
 3 files changed, 97 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt 
b/Documentation/devicetree/bindings/clock/clock-bindings.txt
index 7c52c29..d676112 100644
--- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
+++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -44,6 +44,15 @@ For example:
   clocks by index. The names should reflect the clock output signal
   names for the device.
 
+default-rate:  Sets the rate of the clock during boot to the provided
+   rate.
+
+For example:
+
+clk-divider {
+default-rate = <100>;
+};
+
 ==Clock consumers==
 
 Required properties:
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 5517944..cb144e4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2526,6 +2526,89 @@ const char *of_clk_get_parent_name(struct device_node 
*np, int index)
 }
 EXPORT_SYMBOL_GPL(of_clk_get_parent_name);
 
+static LIST_HEAD(clk_init_info_list);
+
+struct clk_init_info {
+   struct device_node *node;
+   struct clk *clk;
+   u32 rate;
+   struct list_head link;
+   struct list_head sort_link;
+};
+
+int __init of_clk_parse_init_rate(struct device_node *node, struct clk *clk)
+{
+   u32 rate;
+   struct clk_init_info *cinfo;
+
+   if (of_property_read_u32(node, "default-rate", &rate))
+   return 0;
+
+   cinfo = kzalloc(sizeof(*cinfo), GFP_KERNEL);
+   if (!cinfo)
+   return -ENOMEM;
+
+   cinfo->node = node;
+   cinfo->clk = clk;
+   cinfo->rate = rate;
+   list_add(&cinfo->link, &clk_init_info_list);
+   INIT_LIST_HEAD(&cinfo->sort_link);
+
+   return 0;
+}
+
+int __init of_clk_set_init_rates(void)
+{
+   struct clk_init_info *cinfo, *tmp;
+   struct of_phandle_args clkspec;
+   int ret = 0;
+   struct list_head sorted_list;
+   struct clk *clk;
+
+   INIT_LIST_HEAD(&sorted_list);
+
+   list_for_each_entry(cinfo, &clk_init_info_list, link) {
+   /* Get missing clk pointers */
+   if (!cinfo->clk) {
+   clkspec.np = cinfo->node;
+   cinfo->clk = of_clk_get_from_provider(&clkspec);
+   }
+
+   /* Check if we are the parent of any of the sorted clocks */
+   list_for_each_entry(tmp, &sorted_list, sort_link) {
+   clk = tmp->clk;
+   while (clk && clk != cinfo->clk)
+   clk = clk->parent;
+
+   if (clk == cinfo->clk) {
+   /* Add us before this node in the list */
+   list_add_tail(&cinfo->sort_link,
+ &tmp->sort_link);
+   break;
+   }
+   }
+
+   if (list_empty(&cinfo->sort_link))
+   list_add_tail(&cinfo->sort_link, &sorted_list);
+   }
+
+   /* Process sorted list and set clk rates */
+   list_for_each_entry_safe(cinfo, tmp, &sorted_list, sort_link) {
+   int r = clk_set_rate(cinfo->clk, cinfo->rate);
+   if (r) {
+   pr_err("%s: clk_set_rate for %s failed: %d\n", __func__,
+  cinfo->node->name, ret);
+   ret = r;
+   }
+
+   /* Clean up the static list */
+   list_del(&cinfo->link);
+   kfree(cinfo);
+   }
+
+   return ret;
+}
+
 /**
  * of_clk_init() - Scan and init clock providers from the DT
  * @matches: array of compatible values and init functions for providers.
@@ -2544,6 +2627,9 @@ void __init of_clk_init(const struct of_device_id 
*matches)
for_each_matching_node_and_match(np, matches, &match) {
of_clk_init_cb_t clk_init_cb = match->data;
clk_init_cb(np);
+   of_clk_parse_init_rate(np, NULL);
}
+
+   of_clk_set_init_rates();
 }
 #endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 939533d..1bbd194 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -506,6 +506,8 @@ struct clk *of_clk_src_simple_get(struct of_phandle_args 
*clkspec,
 struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void 
*data);
 int of_clk_get_parent_count(struct device_node *np);
 const char *of_clk_get_parent_name(struct device_node *np, int index);
+int of_clk_parse_init_rate(struct device_node *node, struct clk *clk);
+int of_c