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

[Adam Ford]

Tomi,

Do you have any thought on how to approach adding sleep/delay
functions?  I have a display that requires a small delay before and
after the enable gpio toggle.  I assume that some may require a delay
after the regulator starts for it to be be ready.  For now I have a
temp hack that just inserts a blanket 300mS wait, but I'd rather have
something mainstreamed in the device tree, but I don't want to walk
over someone else's work either.

I'd love to help if you have an idea of how you vision it.

adam

On Wed, Dec 16, 2015 at 11:38 AM, Tomi Valkeinen  wrote:
>
>
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/9] phy: ti-pipe3: use *syscon* framework API to power on/off the PHY

[Rob Herring]

On Tue, Dec 15, 2015 at 02:46:05PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to power on/off the PHY and
> use *syscon* framework to do the same.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |   10 ++-
>  drivers/phy/phy-ti-pipe3.c   |   90 
> ++
>  2 files changed, 85 insertions(+), 15 deletions(-)

For the binding:

Acked-by: Rob Herring 

One comment on the driver though.

[...]

> --- a/drivers/phy/phy-ti-pipe3.c
> +++ b/drivers/phy/phy-ti-pipe3.c

[...]

> @@ -144,18 +155,53 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 
> *phy);
>  
>  static int ti_pipe3_power_off(struct phy *x)
>  {
> + u32 val;
> + int ret;
>   struct ti_pipe3 *phy = phy_get_drvdata(x);
>  
> - omap_control_phy_power(phy->control_dev, 0);
> + if (phy->phy_power_syscon) {

Writing this as:

if (!phy->phy_power_syscon) {
...
return 0;
}

//regmap code


will make it simpler to remove the deprecated code later.


> + val = PIPE3_PHY_TX_RX_POWEROFF <<
> + PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
> +
> + ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
> +  PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
> + if (ret < 0)
> + return ret;
> + } else {
> + omap_control_phy_power(phy->control_dev, 0);
> + }
>  
>   return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 7/9] phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY

[Rob Herring]

On Tue, Dec 15, 2015 at 02:46:06PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to set PCS value of the PHY
> and start using *syscon* API to do the same.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Acked-by: Roger Quadros 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
>  drivers/phy/phy-ti-pipe3.c   |   34 
> +-
>  2 files changed, 35 insertions(+), 1 deletion(-)

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

Re: [PATCH v3 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Rob Herring]

On Tue, Dec 15, 2015 at 02:46:08PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to power on/off the PHY,
> and use *syscon* framework to do the same. This handles
> powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
>  drivers/phy/phy-omap-usb2.c  |   94 
> ++
>  include/linux/phy/omap_usb.h |   23 ++
>  3 files changed, 107 insertions(+), 18 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
> b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index 49e5b0c..a3b3945 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -31,6 +31,8 @@ OMAP USB2 PHY
>  
>  Required properties:
>   - compatible: Should be "ti,omap-usb2"
> +Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
> +in DRA7x

The 2nd instance is different somehow?

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

[PATCH] arm: dts: am335x-pepper: fix typo in vmmc-supply property name

[Vladimir Zapolskiy]

Trivial fix of a typo, vmmc-supply should be the right property name.

Signed-off-by: Vladimir Zapolskiy 
---
 arch/arm/boot/dts/am335x-pepper.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index 7106114..a137487 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -351,7 +351,7 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   vmmmc-supply = <_reg>;
+   vmmc-supply = <_reg>;
bus-width = <4>;
ti,non-removable;
dmas = < 12
-- 
2.1.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: BUG: TI CPSW driver hanging up when setting mac-address to early

[Mugunthan V N]

On Thursday 17 December 2015 01:39 PM, Pascal Speck (Iktek) wrote:
> Hi Mugunthan,
> please see my comments below:
> 
> Am 17.12.2015 um 07:08 schrieb 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)?
> Yes, both interfaces are mac-to-mac. The mdio-node is available in the
> dt, but the pinmux has been commented out as the pins are not used.
> These are the relevant parts of the dt:
> 
> ---snip---
> 
> davinci_mdio_default: davinci_mdio_default {
> pinctrl-single,pins = <
> /* MDIO */
> /*  0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
> MUX_MODE0)*/  /* mdio_data.mdio_data */
> /*  0x14c (PIN_OUTPUT_PULLUP |
> MUX_MODE0)   */  /* mdio_clk.mdio_clk */
> >;
> };
> 
> ---snip---
> 
> _emac0 {
> phy-mode = "rgmii";
> dual_emac_res_vlan = <1>;
> /* fixed-link = <1 1000 0 0>; */
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> 
> _emac1 {
> phy-mode = "rmii";
> dual_emac_res_vlan = <2>;
> /* fixed-link = <1 100 0 0>; */
> fixed-link {
> speed = <100>;
> full-duplex;
> };
> };
> 
> 
> _sel {
> rmii-clock-ext;
> };
> 
>  {
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <_default>;
> pinctrl-1 = <_sleep>;
> status = "okay";
> dual_emac;
> };
> 
> _mdio {
> pinctrl-names = "default";
> pinctrl-0 = <_mdio_default>;
> pinctrl-1 = <_mdio_sleep>;
> status = "okay";
> };
> 
> ---snip---
> 
 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.
> I'll try this as soon as possible ( unfortunately this would be
> beginning of next year probably as I'm very busy the last days of the
> year ).
> As the eeprom layout has not been setup by myself, it could take a while
> to reimplement this in kernelspace.
> Would it be a good deal to check somehow if the clocks have been enabled
> before allowing this options to be set by userspace?

You can try accessing the cpsw register space using memtool from userspace.

Even if mdio is enabled in DT, if CPSW is not probed then CPSW clocks
will be in gates state which will cause a crash while accessing its
registers.

Regards
Mugunthan V N

>>
> Thanks for the good opinions. I appreciate your help.
> Regards Pascal
> 

--
To unsubscribe from this list: send the line "unsubscribe 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] mtd: onenand: omap2: Simplify the DMA setup for various paths

[Aaro Koskinen]

Hi,

On Fri, Dec 18, 2015 at 10:39:48AM -0800, Tony Lindgren wrote:
> * Brian Norris  [151218 10:11]:
> > On Mon, Dec 14, 2015 at 11:49:32AM +0200, Peter Ujfalusi wrote:
> > > We have 4 functions containing almost identical DMA setup code. Create one
> > > function which can set up the DMA for both read and write and use this in
> > > place for the setup code in the driver.
> > > The new function will use wait_for_completion_timeout() and it will figure
> > > out the best data_type to be used for the transfer instead of hardwiring
> > > 32 or 16 bit data.
> > > 
> > > Signed-off-by: Peter Ujfalusi 
> > 
> > Does anyone use this driver? I've seen practically zero activity on the
> > entire OneNAND codebase in the last few years, and I presumed it was
> > essentially dead.
> > 
> > If it's not dead, I'd like to know some contingency of people who are
> > willing to actually maintain (or at least review) this stuff.
> > 
> > Kyungmin, are you still out there? Or Tony, do you know of any users for
> > this?
> > 
> > Peter, are you actually using this, or are you just refactoring for the
> > fun of it?
> 
> It's used for n8x0 and n900, but mostly in read-only mode. I suggest we

It's also used on n9/n950 phones. Also write functionality is needed
for mtdoops and kernel flashing.

> remove the DMA support for it completely because of the following:
> 
> 1. The DMA support for this driver is not done correctly. The pin used
>as GPIO should be used as external DMA request line.
> 
> 2. AFAIK the DMA for this driver is mostly disabld, probably largely
>due to #1 above
> 
> 3. If we remove DMA support, we can then easily switch to use the
>generic onenand driver.
> 
> I'd like to hear Aaro's comments too before doing this tough.

Probably DMA support is not that critical. Looks like with DT boot it's
not even possible to enable it at the moment.

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