Re: [PATCH 4/5] fbdev: omap2: panel-dpi: allow specification of a reset gpio

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> Some displays have a reset input. To assert that the display is
> functional the reset gpio must be deasserted.
> 
> Teach the driver to get and drive such a gpio accordingly.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c| 7 +++
>  2 files changed, 8 insertions(+)

DT changes should be posted to devicet...@vger.kernel.org. And, I think,
the binding document changes are usually as a separate patch.

> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt 
> b/Documentation/devicetree/bindings/video/panel-dpi.txt
> index a40180b05bab..1a1d8f6f884f 100644
> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -7,6 +7,7 @@ Required properties:
>  Optional properties:
>  - label: a symbolic name for the panel
>  - enable-gpios: panel enable gpio
> +- reset-gpios: GPIO to control the RESET pin
>  
>  Required nodes:
>  - "panel-timing" containing video timings
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 1216341a0d19..7e2f9e0813dc 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -32,6 +32,7 @@ struct panel_drv_data {
>   int backlight_gpio;
>  
>   struct gpio_desc *enable_gpio;
> + struct gpio_desc *reset_gpio;
>  };
>  
>  #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -83,6 +84,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
>   if (r)
>   return r;
>  
> + gpiod_set_value_cansleep(ddata->reset_gpio, 0);
>   gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>  
>   if (gpio_is_valid(ddata->backlight_gpio))
> @@ -211,6 +213,11 @@ static int panel_dpi_probe_of(struct platform_device 
> *pdev)
>   if (IS_ERR(ddata->enable_gpio))
>   return PTR_ERR(ddata->enable_gpio);
>  
> + ddata->reset_gpio = devm_gpiod_get_optional(>dev,
> + "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ddata->reset_gpio))
> + return PTR_ERR(ddata->reset_gpio);
> +
>   ddata->backlight_gpio = -ENOENT;
>  
>   r = of_get_display_timing(node, "panel-timing", );
> 

This looks a bit odd to me. This only ever sets the reset gpio to 0, on
panel enable. If we never toggle the reset, it could be set to 0 at
probe time, right?

Reset is a bit tricky. I've seen panels where you have to have only a
short reset pulse (reset high, wait a short time, reset low). If you
leave the reset high, the panel draws extra power.

So I think the best we can do in a generic way is just to ensure the
reset is not asserted.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> The variable gpio is only used to store the return value of
> devm_gpiod_get_optional just to assign it to a member of the driver
> data.
> 
> Get rid of this local variable and assign to driver data directly.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index e780fd4f8b46..1216341a0d19 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -205,13 +205,11 @@ static int panel_dpi_probe_of(struct platform_device 
> *pdev)
>   int r;
>   struct display_timing timing;
>   struct videomode vm;
> - struct gpio_desc *gpio;
>  
> - gpio = devm_gpiod_get_optional(>dev, "enable", GPIOD_OUT_LOW);
> - if (IS_ERR(gpio))
> - return PTR_ERR(gpio);
> -
> - ddata->enable_gpio = gpio;
> + ddata->enable_gpio = devm_gpiod_get_optional(>dev,
> +  "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(ddata->enable_gpio))
> + return PTR_ERR(ddata->enable_gpio);
>  
>   ddata->backlight_gpio = -ENOENT;

I usually try to avoid writing bad values to fields. Here
ddata->enable_gpio may get an error ptr. It probably doesn't matter as
we bail out right away, but still. If devm_gpiod_get_optional's return
value would be NULL or valid gpio_desc*, then it'd be fine.

And the code is shorter (more readable) when using just "gpio" instead
of "ddata->enable_gpio".

So I'll leave this one out.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv2] clk: ti: omap5+: dpll: implement errata i810

[Tony Lindgren]

* Tero Kristo  [151216 01:00]:
> Errata i810 states that DPLL controller can get stuck while transitioning
> to a power saving state, while its M/N ratio is being re-programmed.
> 
> As a workaround, before re-programming the M/N ratio, SW has to ensure
> the DPLL cannot start an idle state transition. SW can disable DPLL
> idling by setting the DPLL AUTO_DPLL_MODE=0 or keeping a clock request
> active by setting a dependent clock domain in SW_WKUP.
> 
> This errata is known to impact OMAP5 and DRA7 chips, but lets enable it
> unconditionally to avoid any potential problems with earlier generation
> SoCs also.
> 
> Signed-off-by: Tero Kristo 
> ---
> v2: made the fix to be applied unconditionally on all OMAP3+ SoCs

Thanks looks good to me now:

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

Re: [PATCH 1/5] fbdev: omap2: panel-dpi: in .disable first disable backlight then display

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> This makes .disable operate in reverse order compared to .enable.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index f7be3489f744..06b6e611e4b2 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -102,12 +102,12 @@ static void panel_dpi_disable(struct omap_dss_device 
> *dssdev)
>   if (!omapdss_device_is_enabled(dssdev))
>   return;
>  
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> -
>   if (gpio_is_valid(ddata->backlight_gpio))
>   gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>  
> + if (ddata->enable_gpio)
> + gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> +
>   in->ops.dpi->disable(in);
>  
>   dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
> 

Thanks, queued for 4.5.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> To allow supporting displays that need some logic to enable power to the
> display add support for a vcc-supply property to drive a regulator.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  Documentation/devicetree/bindings/video/panel-dpi.txt |  1 +
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c| 13 +
>  2 files changed, 14 insertions(+)

Same comments here about the bindings.

> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt 
> b/Documentation/devicetree/bindings/video/panel-dpi.txt
> index 1a1d8f6f884f..eaa39d1b1279 100644
> --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> @@ -8,6 +8,7 @@ Optional properties:
>  - label: a symbolic name for the panel
>  - enable-gpios: panel enable gpio
>  - reset-gpios: GPIO to control the RESET pin
> +- vcc-supply: phandle of regulator that will be used to enable power to the 
> display
>  
>  Required nodes:
>  - "panel-timing" containing video timings
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 7e2f9e0813dc..65c6d9e6862b 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -33,6 +34,7 @@ struct panel_drv_data {
>  
>   struct gpio_desc *enable_gpio;
>   struct gpio_desc *reset_gpio;
> + struct regulator *vcc_supply;
>  };
>  
>  #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> @@ -84,6 +86,12 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
>   if (r)
>   return r;
>  
> + r = regulator_enable(ddata->vcc_supply);
> + if (r) {
> + in->ops.dpi->disable(in);
> + return r;
> + }
> +
>   gpiod_set_value_cansleep(ddata->reset_gpio, 0);
>   gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>  
> @@ -107,6 +115,7 @@ static void panel_dpi_disable(struct omap_dss_device 
> *dssdev)
>   gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>  
>   gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> + regulator_disable(ddata->vcc_supply);
>  
>   in->ops.dpi->disable(in);
>  
> @@ -218,6 +227,10 @@ static int panel_dpi_probe_of(struct platform_device 
> *pdev)
>   if (IS_ERR(ddata->reset_gpio))
>   return PTR_ERR(ddata->reset_gpio);
>  
> + ddata->vcc_supply = devm_regulator_get(>dev, "vcc");
> + if (IS_ERR(ddata->vcc_supply))
> + return PTR_ERR(ddata->vcc_supply);
> +
>   ddata->backlight_gpio = -ENOENT;
>  
>   r = of_get_display_timing(node, "panel-timing", );

Some panels might need to sleep before/after the regulator, but the same
goes for enable gpio. And we don't have a sane way to handle that at the
moment, so I think this is fine.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/5] fbdev: omap2: panel-dpi: simplify gpio setting

[Tomi Valkeinen]

On 10/12/15 15:11, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
> 
> gpiod_set_value_cansleep is a noop when the passed descriptor is NULL.
> So there is no need to duplicate the check for NULL; just call the
> function unconditionally instead.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> index 06b6e611e4b2..e780fd4f8b46 100644
> --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> @@ -83,8 +83,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
>   if (r)
>   return r;
>  
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 1);
> + gpiod_set_value_cansleep(ddata->enable_gpio, 1);
>  
>   if (gpio_is_valid(ddata->backlight_gpio))
>   gpio_set_value_cansleep(ddata->backlight_gpio, 1);
> @@ -105,8 +104,7 @@ static void panel_dpi_disable(struct omap_dss_device 
> *dssdev)
>   if (gpio_is_valid(ddata->backlight_gpio))
>   gpio_set_value_cansleep(ddata->backlight_gpio, 0);
>  
> - if (ddata->enable_gpio)
> - gpiod_set_value_cansleep(ddata->enable_gpio, 0);
> + gpiod_set_value_cansleep(ddata->enable_gpio, 0);
>  
>   in->ops.dpi->disable(in);
>  
> 

Thanks, queued for 4.5.

Tomi



signature.asc
Description: OpenPGP digital signature

[PATCH V2] ARM: OMAP2+: LogicPD Torpedo + Wireless: Add Bluetooth

[Adam Ford]

Bindings for the WL1283 Bluetooth was removed from the shared transport
driver in commit c0bd1b9e5895 ("Revert ti-st: add device tree support")
Until we havea better binding, we need to use the platform data to
initialize Bluetooth.

Signed-off-by: Adam Ford 
---
 arch/arm/mach-omap2/pdata-quirks.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index e097055..e781e4f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -150,6 +150,21 @@ static struct platform_device wl18xx_device = {
}
 };
 
+static struct ti_st_plat_data wilink7_pdata = {
+   .nshutdown_gpio = 162,
+   .dev_name = "/dev/ttyO1",
+   .flow_cntrl = 1,
+   .baud_rate = 30,
+};
+
+static struct platform_device wl128x_device = {
+   .name   = "kim",
+   .id = -1,
+   .dev= {
+   .platform_data = _pdata,
+   }
+};
+
 static struct platform_device btwilink_device = {
.name   = "btwilink",
.id = -1,
@@ -276,6 +291,13 @@ static void __init omap3_tao3530_legacy_init(void)
hsmmc2_internal_input_clk();
 }
 
+static void __init omap3_logicpd_torpedo_init(void)
+{
+   omap3_gpio126_127_129();
+   platform_device_register(_device);
+   platform_device_register(_device);
+}
+
 /* omap3pandora legacy devices */
 #define PANDORA_WIFI_IRQ_GPIO  21
 #define PANDORA_WIFI_NRESET_GPIO   23
@@ -503,7 +525,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ "nokia,omap3-n950", hsmmc2_internal_input_clk, },
{ "isee,omap3-igep0020-rev-f", omap3_igep0020_rev_f_legacy_init, },
{ "isee,omap3-igep0030-rev-g", omap3_igep0030_rev_g_legacy_init, },
-   { "logicpd,dm3730-torpedo-devkit", omap3_gpio126_127_129, },
+   { "logicpd,dm3730-torpedo-devkit", omap3_logicpd_torpedo_init, },
{ "ti,omap3-evm-37xx", omap3_evm_legacy_init, },
{ "ti,am3517-evm", am3517_evm_legacy_init, },
{ "technexion,omap3-tao3530", omap3_tao3530_legacy_init, },
-- 
1.9.1

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

[PATCH] ARM: OMAP2+: LogicPD Torpedo + Wireless: Revert duplicative DTS entries

[Adam Ford]

Revert commit 6f0f6c40b66 ("ARM: dts: Set VAUX1 and VAUX4 on Logic PD Torpedo")
because it It was already done and it's just a duplicate.  See:
commit 2d11961f3e55 ("ARM: dts: Set VAUX1 and VAUX4 to 3.0V and 1.8V 
respectively")
---
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index b017871..b07d1d9 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -83,16 +83,6 @@
regulator-max-microvolt = <180>;
 };
 
- {
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
-};
-
- {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-};
-
  {
status = "okay";
 };
-- 
1.9.1

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

Re: BUG: TI CPSW driver hanging up when setting mac-address to early

[Mugunthan V N]

On Tuesday 08 December 2015 09:55 PM, Tony Lindgren wrote:
> * ker...@iktek.de  [151207 09:17]:
>> Hi Tony,
>>
>> there are two ethernet interfaces ( dual-emac-configuration ) used.
>> One is connected to another 100mbit switch-ic ( refclk should come from
>> switch ic ) via rmii, the other one is connected to a 1gbit fpga rgmii
>> interface ( where the clock is served from the fpga ).

This means you have both the interfaces with MAC-to-MAC interface. Is
MDIO is active or did you disabled it as it is not needed (because of no
phy present in the system)?

>>
>> On both interfaces it may happen that the clock isn't present while the
>> mac-address is set (fpga may not have been inited, switch chip could be
>> held in reset), but this was the same behaviour with previous kernel
>> (3.14 with cpsw patched from ti tree) where this configuration worked.
>> As the hardware is in field now there is no chance to change hardware.
>>
>> On the other hand: when not setting the mac of the interface that early,
>> the cpsw seems to init proberly but a ping to the outer world does not
>> work either, so something else may be different on the new kernel.
> 
> Maybe Mugunthan has some ideas what's going on here.
> 

If MDIO is disabled and CPSW is not brought up then  CPSW clocks are
gated and when you try to set the mac address the system will crash as
the driver try to access CPSW registers with CPSW clocks gated. Can you
try below options and see what happens

* Instead of setting the mac address using *ip link set address*, try to
use u-boot env variable (ethaddr/ath1addr) to set the mac address.

* You must be storing the MAC address in EEPROM or somewhere, just try
to implement the mac address reading mechanism in
drivers/net/ethernet/ti/cpsw-common.c file to avoid setting of mac
address from userspace.

Regards
Mugunthan V N

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

Re: [PATCH] drivers: net: cpsw: fix RMII/RGMII mode when used with fixed-link PHY

[David Rivshin (Allworx)]

On Wed, 16 Dec 2015 07:39:16 +0100
Markus Brunner  wrote:

> On Monday 14 December 2015 13:04:46 David Rivshin wrote:
> > On Sat, 12 Dec 2015 16:44:19 +0100
> ...
> > > Your patch works fine on my board, which uses MII and dual_emac
> > > with a fixed_phy and a real one.
> > 
> > Thanks for checking. The only dual_emac board I have available is
> > the EVMSK, which has two real PHYs. I'm not sure of the usual
> > etiquette (and Google was  unhelpful), should I add a Tested-by on
> > the next version?
> > 
> Yes you can. Documentation/SubmittingPatches has some notes about it.

Thanks, I didn't want to throw it on without permission. Although due 
to the non-trivial change I mention below, I figured that the previous 
testing wasn't totally valid anymore anyways, so I left it off the v2 
emails.

> > > I wanted to keep changes small and didn't spend too much thinking
> > > about already broken devicetrees. Since my patch is quite new, I
> > 
> > I'm honestly not sure it's an important consideration myself. Most
> > patches I've seen in this area for this or other drivers do not take
> > such behavior into account (e.g. the phy-handle parsing that went in
> > to cpsw in 4.3).
> > I would generally feel more comfortable with such a behavior tweak
> > (minor as it is) before 4.4 is released, to avoid ping-ponging the
> > behavior. But given how far along the cycle is, I'm not sure about
> > the chances of that.
> 
> Well I don't think compatibility for flawed DTs is such a high
> priority, especially if it is that unlikely that there are some
> affected. Keep the focus on the other _real_ problems you have
> encountered and fix those like you see fit. 

Since there's been no indication from anyone that being nice to such
broken DTs is desired, I decided to drop that aspect of the patch and 
leave the current 4.4-rc1..5 behavior. This also made it much more 
reasonable to chop up the patch into smaller pieces, which I think will 
be easier to review.

> > > don't see any problems with subtle changes like that. However you
> > > should update the documentation as well.
> > 
> > Your patch already updated .../bindings/net/cpsw.txt, which this
> > patch left alone. Are you referring to some other documentation,
> > or do you think I should update the binding documentation to state
> > that phy_id takes precedence over fixed-link? I figured that such
> > devicetrees were still officially malformed, so I thought the
> > existing text was appropriate.
> 
> "Either the properties phy_id and phy-mode, or the sub-node
> fixed-link can be specified" One flaw of my patch was to ignore the
> phy-mode for a fixed link. Do not mention the precedence of the
> phy_id, because it is an undefined behavior. Your patch should change
> it to: "Either the property phy_id, or the sub-node fixed-link can be
> specified"

Thanks for pointing that out. For some reason my brain skipped over the 
"and phy-mode" part. Fixed in v2.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] drivers: net: cpsw: Fix bugs in fixed-link PHY DT parsing

[David Rivshin (Allworx)]

Commit 1f71e8c96fc654724723ce987e0a8b2aeb81746d ("drivers: net: cpsw:
Add support for fixed-link PHY") added initial fixed-link PHY support
for CPSW, but missed a few considerations.

This series is based on the tip of the net tree. The first two patches
fix user-visible errors in different hardware configurations. The third
patch is for an internal reference counting issue. They are logically
independent changes, but in the same function, so must be applied in
order to apply cleanly.

The first patch was originally submitted by Pascal Speck on December 4,
but was not picked up by patchwork. I suspect that is because the patch
was mangled by the mailer. I fixed the mangling and am including it in
this series, as I believe it is the correct change.

I have tested on the following hardware configurations:
 - (EVMSK) dual emac with two real MDIO-connected phys using RGMII-TXID
 - single emac with fixed-link using RGMII
Testing of other CPSW emac configurations that folks may have would
be appreciated.


Changes from v1 [1]:
 - Split into 3 smaller patches.
 - Maintain 1f71e8c96fc6's preference for fixed-link over phy_id if
   they are both (incorrectly) specified in the slave node.
 - Update binding documentation to no longer say that phy_mode is also
   mutually exclusive with fixed-link.
 - Dropped unnecessary include of phy_fixed.h.

[1] https://patchwork.ozlabs.org/patch/554989/

David Rivshin (2):
  drivers: net: cpsw: fix RMII/RGMII mode when used with fixed-link PHY
  drivers: net: cpsw: increment reference count on fixed-link PHY node

Pascal Speck (Iktek) (1):
  ethernet:ti:cpsw: fix phy identification with multiple slaves on
fixed-phy

 Documentation/devicetree/bindings/net/cpsw.txt |  6 +--
 drivers/net/ethernet/ti/cpsw.c | 53 +++---
 2 files changed, 34 insertions(+), 25 deletions(-)

--
2.5.0

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

[PATCH v2 2/3] drivers: net: cpsw: fix RMII/RGMII mode when used with fixed-link PHY

[David Rivshin (Allworx)]

From: David Rivshin 

Commit 1f71e8c96fc654724723ce987e0a8b2aeb81746d ("drivers: net: cpsw: Add
support for fixed-link PHY") did not parse the "phy-mode" property in
the case of a fixed-link PHY, leaving slave_data->phy_if with its default
of PHY_INTERFACE_MODE_NA(0). This later gets passed to phy_connect() in
cpsw_slave_open(), and eventually to cpsw_phy_sel() where it hits a default
case that configures the MAC for MII mode.

The user visible symptom is that while kernel log messages seem to indicate
that the interface is set up, there is no network communication. Eventually
a watchdog error occurs:
NETDEV WATCHDOG: eth0 (cpsw): transmit queue 0 timed out

Fixes: 1f71e8c96fc6 ("drivers: net: cpsw: Add support for fixed-link PHY")
Signed-off-by: David Rivshin 
---
Changes from v1 (https://patchwork.ozlabs.org/patch/554989/):
 - Maintain 1f71e8c96fc6's preference for fixed-link over phy_id if they
   are both (incorrectly) specified in the slave node.
 - Update binding documentation to no longer say that phy_mode is also
   mutually exclusive with fixed-link.
 - Dropped unnecessary include of phy_fixed.h.
 - Commit message tweaked.

 Documentation/devicetree/bindings/net/cpsw.txt |  6 ++--
 drivers/net/ethernet/ti/cpsw.c | 40 ++
 2 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 9853f8e..28a4781 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -40,18 +40,18 @@ Optional properties:

 Slave Properties:
 Required properties:
-- phy_id   : Specifies slave phy id
 - phy-mode : See ethernet.txt file in the same directory

 Optional properties:
 - dual_emac_res_vlan   : Specifies VID to be used to segregate the ports
 - mac-address  : See ethernet.txt file in the same directory
+- phy_id   : Specifies slave phy id
 - phy-handle   : See ethernet.txt file in the same directory

 Slave sub-nodes:
 - fixed-link   : See fixed-link.txt file in the same directory
- Either the properties phy_id and phy-mode,
- or the sub-node fixed-link can be specified
+ Either the property phy_id, or the sub-node
+ fixed-link can be specified

 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 e3b220d..bc6d20d 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2026,17 +2026,15 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
for_each_child_of_node(node, slave_node) {
struct cpsw_slave_data *slave_data = data->slave_data + i;
const void *mac_addr = NULL;
-   u32 phyid;
int lenp;
const __be32 *parp;
-   struct device_node *mdio_node;
-   struct platform_device *mdio;

/* This is no slave child node, continue */
if (strcmp(slave_node->name, "slave"))
continue;

priv->phy_node = of_parse_phandle(slave_node, "phy-handle", 0);
+   parp = of_get_property(slave_node, "phy_id", );
if (of_phy_is_fixed_link(slave_node)) {
struct phy_device *pd;

@@ -2048,23 +2046,29 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
return -ENODEV;
snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
 PHY_ID_FMT, pd->bus->id, pd->addr);
+   } else if (parp) {
+   u32 phyid;
+   struct device_node *mdio_node;
+   struct platform_device *mdio;
+
+   if (lenp != (sizeof(__be32) * 2)) {
+   dev_err(>dev, "Invalid slave[%d] phy_id 
property\n", i);
+   goto no_phy_slave;
+   }
+   mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
+   phyid = be32_to_cpup(parp+1);
+   mdio = of_find_device_by_node(mdio_node);
+   of_node_put(mdio_node);
+   if (!mdio) {
+   dev_err(>dev, "Missing mdio platform 
device\n");
+   return -EINVAL;
+   }
+   snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
+PHY_ID_FMT, mdio->name, phyid);
+   } else {
+   dev_err(>dev, "No slave[%d] phy_id or fixed-link 

[PATCH v2 1/3] ethernet:ti:cpsw: fix phy identification with multiple slaves on fixed-phy

[David Rivshin (Allworx)]

From: Pascal Speck (Iktek) 
Date: Fri, 04 Dec 2015 16:55:17 +0100

When using more than one slave with ti cpsw and fixed phy the pd->phy_id
will be always zero, but slave_data->phy_id must be unique. pd->phy_id
means a "phy hardware id" whereas slave_data->phy_id means an "unique id",
so we should use pd->addr which has the same unique meaning.

Fixes: 1f71e8c96fc6 ("drivers: net: cpsw: Add support for fixed-link PHY")
Signed-off-by: Pascal Speck 
---
This was originally submitted by Pascal Speck on December 4, but was not
picked up by patchwork. I suspect that is because the patch was mangled by
the mailer. The only changes I made were to manually fix the patch whitespace
and wrapping, and add the Fixes: tag.

 drivers/net/ethernet/ti/cpsw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 48b92c9..e3b220d 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2047,7 +2047,7 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
if (!pd)
return -ENODEV;
snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
-PHY_ID_FMT, pd->bus->id, pd->phy_id);
+PHY_ID_FMT, pd->bus->id, pd->addr);
goto no_phy_slave;
}
parp = of_get_property(slave_node, "phy_id", );
--
2.5.0

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

[PATCH v2 3/3] drivers: net: cpsw: increment reference count on fixed-link PHY node

[David Rivshin (Allworx)]

From: David Rivshin 

When a fixed-link sub-node exists in a slave node, the slave node
is also the PHY node. Since this is a separate use of the slave node,
of_node_get() should be used to increment the reference count.

Fixes: 1f71e8c96fc6 ("drivers: net: cpsw: Add support for fixed-link PHY")
Signed-off-by: David Rivshin 
---
'pd' was renamed to 'phy_dev' to better fit the naming convention in the
function/file.

 drivers/net/ethernet/ti/cpsw.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index bc6d20d..3b489ca 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2036,16 +2036,21 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
priv->phy_node = of_parse_phandle(slave_node, "phy-handle", 0);
parp = of_get_property(slave_node, "phy_id", );
if (of_phy_is_fixed_link(slave_node)) {
-   struct phy_device *pd;
+   struct device_node *phy_node;
+   struct phy_device *phy_dev;

+   /* In the case of a fixed PHY, the DT node associated
+* to the PHY is the Ethernet MAC DT node.
+*/
ret = of_phy_register_fixed_link(slave_node);
if (ret)
return ret;
-   pd = of_phy_find_device(slave_node);
-   if (!pd)
+   phy_node = of_node_get(slave_node);
+   phy_dev = of_phy_find_device(phy_node);
+   if (!phy_dev)
return -ENODEV;
snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
-PHY_ID_FMT, pd->bus->id, pd->addr);
+PHY_ID_FMT, phy_dev->bus->id, phy_dev->addr);
} else if (parp) {
u32 phyid;
struct device_node *mdio_node;
--
2.5.0

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

[PATCH] ARM: OMAP2+: LogicPD Torpedo: Add LCD Type 15 Support

[Adam Ford]

Add basic support for Logic PD type 15 display for older development kits.
This uses GPIO for the backlight.

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 110 --
 1 file changed, 100 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index b017871..1b9e1cf 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -114,6 +104,70 @@
};
 };
 
+ {
+   regulator-always-on;
+};
+
+ {
+   status = "ok";
+   vdds_dsi-supply = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_dpi_pins1>;
+   port {
+   dpi_out: endpoint {
+   remote-endpoint = <_in>;
+   data-lines = <16>;
+   };
+   };
+};
+
+/ {
+   aliases {
+   display0 = 
+   };
+
+   lcd0: display@0 {
+   compatible = "panel-dpi";
+   label = "15";
+   status = "okay";
+   /* default-on; */
+   pinctrl-names = "default";
+   enable-gpios = < 27 GPIO_ACTIVE_HIGH>;/* gpio155, lcd 
INI */
+
+   port {
+   lcd_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   panel-timing {
+   clock-frequency = <900>;
+   hactive = <480>;
+   vactive = <272>;
+   hfront-porch = <3>;
+   hback-porch = <2>;
+   hsync-len = <42>;
+   vback-porch = <3>;
+   vfront-porch = <4>;
+   vsync-len = <11>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <1>;
+   pixelclk-active = <1>;
+   };
+   };
+
+   bl: backlight {
+   compatible = "gpio-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   gpios = < 24 GPIO_ACTIVE_HIGH>, /* gpio_56 */
+   < 26 GPIO_ACTIVE_HIGH>; /* gpio_154 */
+   default-on;
+   };
+};
+
  {
interrupts-extended = < 83 _pmx_core 0x11a>;
pinctrl-names = "default";
@@ -149,6 +203,42 @@
OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT | MUX_MODE0)
/* sdmmc1_dat3.sdmmc1_dat3 */
>;
};
+
+   backlight_pins: pinmux_backlight_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x20B8, PIN_OUTPUT | MUX_MODE4)   
/* gpmc_ncs5.gpio_56 */
+   OMAP3_CORE1_IOPAD(0x2188, PIN_OUTPUT | MUX_MODE4)   
/* mcbsp4_dx.gpio_154 */
+   >;
+   };
+
+   dss_dpi_pins1: pinmux_dss_dpi_pins1 {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_pclk.dss_pclk */
+   OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_hsync.dss_hsync */
+   OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_vsync.dss_vsync */
+   OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* 
dss_acbias.dss_acbias */
+
+   OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data6.dss_data6 */
+   OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data7.dss_data7 */
+   OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data8.dss_data8 */
+   OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data9.dss_data9 */
+   OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data10.dss_data10 */
+   OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data11.dss_data11 */
+   OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data12.dss_data12 */
+   OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data13.dss_data13 */
+   OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data14.dss_data14 */
+   OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data15.dss_data15 */
+   OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data16.dss_data16 */
+   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data17.dss_data17 */
+
+   OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data18.dss_data0 */
+   OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data19.dss_data1 */
+   

[PATCH] dmaengine: edma: Add probe callback to edma_tptc_driver

[Peter Ujfalusi]

Due to changes in device and platform code drivers w/o probe will fail to
load. This means that the devices for eDMA TPTCs are goign to be without
driver and omap hwmod code will turn them off after the kernel finished
loading:
[3.015900] platform 4980.tptc: omap_device_late_idle: enabled but no 
driver.  Idling
[3.024671] platform 49a0.tptc: omap_device_late_idle: enabled but no 
driver.  Idling

This will prevent eDMA to work since the TPTCs are not enabled.

Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Fixes: 34635b1accb9 ("dmaengine: edma: Add dummy driver skeleton for 
edma3-tptc")
---
Hi,

The issue surfaced with next-20151216, next-20151214 was worked fine.

Regards,
Peter

 drivers/dma/edma.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2e8acde6b134..50584015e046 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2425,7 +2425,13 @@ static struct platform_driver edma_driver = {
},
 };
 
+static int edma_tptc_probe(struct platform_device *pdev)
+{
+   return 0;
+}
+
 static struct platform_driver edma_tptc_driver = {
+   .probe  = edma_tptc_probe,
.driver = {
.name   = "edma3-tptc",
.of_match_table = edma_tptc_of_ids,
-- 
2.6.4

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

Re: [PATCH 2/3] pwm: Add PWM driver for OMAP using dual-mode timers

[Thierry Reding]

On Mon, Nov 02, 2015 at 12:14:21PM +0100, Neil Armstrong wrote:
> Adds support for using a OMAP dual-mode timer with PWM capability
> as a Linux PWM device. The driver controls the timer by using the
> dmtimer API.
> 
> Add a platform_data structure for each pwm-omap-dmtimer nodes containing
> the dmtimers functions in order to get driver not rely on platform
> specific functions.
> 
> Cc: Grant Erickson 
> Cc: NeilBrown 
> Cc: Joachim Eastwood 
> Suggested-by: Tony Lindgren 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt   |  18 ++
>  drivers/pwm/Kconfig|   9 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-omap-dmtimer.c | 322 
> +
>  include/linux/platform_data/pwm_omap_dmtimer.h |  69 +
>  5 files changed, 419 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
>  create mode 100644 drivers/pwm/pwm-omap-dmtimer.c
>  create mode 100644 include/linux/platform_data/pwm_omap_dmtimer.h

I've applied this with some coding style bikeshedding applied. Also I
think there's a timer leak in the probe function:

> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
[...]
> +static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> +{
[...]
> + dm_timer = pdata->request_by_node(timer);
> + if (!dm_timer)
> + return -EPROBE_DEFER;

dm_timer holds the requested timer now.

> +
> + omap = devm_kzalloc(>dev, sizeof(*omap), GFP_KERNEL);
> + if (!omap)
> + return -ENOMEM;

But it's not released when this allocation fails...

> +
> + omap->pdata = pdata;
> + omap->dm_timer = dm_timer;
> + omap->dm_timer_pdev = of_find_device_by_node(timer);
> + if (!omap->dm_timer_pdev) {
> + dev_err(>dev, "Unable to find timer pdev\n");
> + return -EINVAL;
> + }

... nor when this lookup fails. I've taken the liberty of adding two
calls to omap->pdata->free(dm_timer) to these error paths.

Please take a look at what's in the pwm/for-next branch to see if it
still works correctly.

Thanks,
Thierry


signature.asc
Description: PGP signature

[PATCHv2] clk: ti: omap5+: dpll: implement errata i810

[Tero Kristo]

Errata i810 states that DPLL controller can get stuck while transitioning
to a power saving state, while its M/N ratio is being re-programmed.

As a workaround, before re-programming the M/N ratio, SW has to ensure
the DPLL cannot start an idle state transition. SW can disable DPLL
idling by setting the DPLL AUTO_DPLL_MODE=0 or keeping a clock request
active by setting a dependent clock domain in SW_WKUP.

This errata is known to impact OMAP5 and DRA7 chips, but lets enable it
unconditionally to avoid any potential problems with earlier generation
SoCs also.

Signed-off-by: Tero Kristo 
---
v2: made the fix to be applied unconditionally on all OMAP3+ SoCs

 drivers/clk/ti/dpll3xxx.c |   20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/dpll3xxx.c b/drivers/clk/ti/dpll3xxx.c
index f4dec00..cb26eb8 100644
--- a/drivers/clk/ti/dpll3xxx.c
+++ b/drivers/clk/ti/dpll3xxx.c
@@ -305,7 +305,7 @@ static void _lookup_sddiv(struct clk_hw_omap *clk, u8 
*sd_div, u16 m, u8 n)
 static int omap3_noncore_dpll_program(struct clk_hw_omap *clk, u16 freqsel)
 {
struct dpll_data *dd = clk->dpll_data;
-   u8 dco, sd_div;
+   u8 dco, sd_div, ai = 0;
u32 v;
 
/* 3430 ES2 TRM: 4.7.6.9 DPLL Programming Sequence */
@@ -350,6 +350,21 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap 
*clk, u16 freqsel)
v |= sd_div << __ffs(dd->sddiv_mask);
}
 
+   /*
+* Errata i810 - DPLL controller can get stuck while transitioning
+* to a power saving state. Software must ensure the DPLL can not
+* transition to a low power state while changing M/N values.
+* Easiest way to accomplish this is to prevent DPLL autoidle
+* before doing the M/N re-program.
+*/
+   ai = omap3_dpll_autoidle_read(clk);
+   if (ai) {
+   omap3_dpll_deny_idle(clk);
+
+   /* OCP barrier */
+   omap3_dpll_autoidle_read(clk);
+   }
+
ti_clk_ll_ops->clk_writel(v, dd->mult_div1_reg);
 
/* Set 4X multiplier and low-power mode */
@@ -379,6 +394,9 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap 
*clk, u16 freqsel)
 
_omap3_noncore_dpll_lock(clk);
 
+   if (ai)
+   omap3_dpll_allow_idle(clk);
+
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