Revert "ARM: dts: dra74x: Enable 1.5GHz"

This reverts commit ebaf0b6ee165b8f058675ca05fb1485b8ec762db.

Higher OPPs will be enabled by opp7xx_data now.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Revert "ARM: dts: dra72x: Enable 1.5GHz"

This reverts commit 874f0515c29dff4f3dd0debe45cb96639bdb8979.

Higher OPPs will be enabled by opp7xx_data now.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: dra74x: Remove non-common cpu0 operating-points

Remove all OPPs that are not common to all dra74x variants.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: dra72x: Add basic OPPs for MPU

Add basic OPPs for MPU that will be present if no other driver steps in
to enable higher OPPs based on SoC configuration.

Data based on DRA7x Data Manual, SPRS857K, Revised July 2014,
Section 5.3.1.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am43x-epos-evm: Hook dcdc2 as the cpu0-supply

Hook dcdc2 as the cpu0-supply.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am437x-gp-evm: Hook dcdc2 as the cpu0-supply

Hook dcdc2 as the cpu0-supply.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am437x-sk-evm: Hook dcdc2 as the cpu0-supply

Hook dcdc2 as the cpu0-supply.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am4372: Add voltage-tolerance to cpu node

Allow for a voltage-tolerance so that cpufreq can adjust the voltage to
the closest acceptable voltage for an OPP rather than an exact voltage
that may or may not exist.

Tolerance value calculated from Table 5.3 in section 5.4 of AM437x
Data Manual, SPRS851, June 2014.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: am33xx: Drop operating-points table from cpu0

We now depend on platform code to provide opp table based on various
SoC factors so drop dt operating-points table as there are no
OPPs present which are common to all silicon.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
cpufreq: cpu0: OPPs can be populated at runtime

OPPs can be populated statically, via DT, or added at run time with
dev_pm_opp_add().

While this driver handles the first case correctly, it would fail to populate
OPPs added at runtime. Because call to of_init_opp_table() would fail as there
are no OPPs in DT and probe will return early.

To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table()
unconditionally.

Update bindings as well.

Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[d-gerlach@ti.com: Modified to apply after voltage notifier series]
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: opp: Move dt check from omap_init_opp_table

omap_init_opp_table previously would return if dt was present however we
can still use this function even if dt is present to give updated OPP
table based on SoC conditions like eFuse. Move the dt check to the
platform specific opp init functions that don't support eFuse check.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: opp: Add helper functions for variable OPP handling

Add opp_def_list_enable_opp to enable an opp in the opp_def_list
based on frequency and opp_def_list_update_opp_voltage to change
the voltage of an opp in the opp_def_list to aid in constructing
an OPP table based on eFuse values.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: AM33XX: Add opp33xx_data to enable higher OPPs

The availability of certain higher OPPs on AM33XX is defined by a
register value and they can differ between silicon revisions. Define a
table containing this information to properly enable OPPs for cpufreq.

OPP information from AM335x Data Manual, SPRS717F, Revised April 2013.

efuse_sma values decoded using "Device_Attribute_ Bit Requests_v0.1.pptx"
Revised 9/11/2013.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: AM43XX: Add opp43xx_data to enable higher OPPs

Certain OPPs on AM43XX are not available for all variants. The available
OPPs can be determined by reading a device_attr register. This patch
reads the register and enables the appropriate OPPs.

OPP Information from AM437x Data Manual, SPRS851, June 2014.

dev_atrribute values decoded using "Device_Attribute_ Bit Requests_v0.1.pptx"
Revised 9/11/2013.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: DRA7XX: Add opp7xx_data to enable higher OPPs

Certain OPPs on DRA7XX are not available for all variants. The available
OPPs can be determined by reading a die_id register. This patch
reads the register and enables the appropriate OPPs.

OPP Information from DRA7x Data Manual, SPRS857K, Revised July 2014.

efuse decoded using VayuSpeedGrades.xlsx document, version 0.2, revised
May 30, 2014.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ti: config: connectivity: Enable QSPI

Enable QSPI in TI connectivity configs.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[nsekhar@ti.com: made the flash driver a module]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  ti: config: connectivity: Enable QSPI

Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y

TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y

* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
  ARM: OMAP2+: DRA7XX: Add opp7xx_data to enable higher OPPs
  ARM: OMAP2+: AM43XX: Add opp43xx_data to enable higher OPPs
  ARM: OMAP2+: AM33XX: Add opp33xx_data to enable higher OPPs
  ARM: OMAP2+: opp: Add helper functions for variable OPP handling
  ARM: OMAP2+: opp: Move dt check from omap_init_opp_table
  cpufreq: cpu0: OPPs can be populated at runtime
  ARM: dts: am33xx: Drop operating-points table from cpu0
  ARM: dts: am4372: Add voltage-tolerance to cpu node
  ARM: dts: am437x-sk-evm: Hook dcdc2 as the cpu0-supply
  ARM: dts: am437x-gp-evm: Hook dcdc2 as the cpu0-supply
  ARM: dts: am43x-epos-evm: Hook dcdc2 as the cpu0-supply
  ARM: dts: dra72x: Add basic OPPs for MPU
  ARM: dts: dra74x: Remove non-common cpu0 operating-points
  Revert "ARM: dts: dra72x: Enable 1.5GHz"
  Revert "ARM: dts: dra74x: Enable 1.5GHz"

Conflicts:
	arch/arm/boot/dts/am437x-gp-evm.dts
	arch/arm/boot/dts/am43x-epos-evm.dts

Signed-off-by: Dan Murphy <DMurphy@ti.com>
usb: Check if port status is equal to RxDetect

commit bb86cf569bbd7ad4dce581a37c7fbd748057e9dc upstream.

When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing
hub_usb3_port_disable().

Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: chipidea: udc: Disable auto ZLP generation on ep0

commit 953c66469735aed8d2ada639a72b150f01dae605 upstream.

There are 2 methods for ZLP (zero-length packet) generation:
1) In software
2) Automatic generation by device controller

1) is implemented in UDC driver and it attaches ZLP to IN packet if
   descriptor->size < wLength
2) can be enabled/disabled by setting ZLT bit in the QH

When gadget ffs is connected to ubuntu host, the host sends
get descriptor request and wLength in setup packet is 255 while the
size of descriptor which will be sent by gadget in IN packet is
64 byte. So the composite driver sets req->zero = 1.
In UDC driver following code will be executed then

        if (hwreq->req.zero && hwreq->req.length
            && (hwreq->req.length % hwep->ep.maxpacket == 0))
                add_td_to_list(hwep, hwreq, 0);

Case-A:
So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
ubuntu host will request 255 byte in IN request, gadget will send 64 byte
with ZLP and host will come to know that there is no more data.
But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
automatically generate the ZLP which blocks enumeration for ~6 seconds due
to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)

Case-B:
In case when gadget ffs is connected to Apple device, Apple device sends
setup packet with wLength=64. So descriptor->size = 64 and wLength=64
therefore req->zero = 0 and UDC driver will not attach any ZLP to the
IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
further request for IN data. But ZLT=0 by default for endpoint 0 so
hardware tries to automatically generate the ZLP which blocks enumeration
for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
requests (OUT/PING)

According to USB2.0 specs:

    8.5.3.2 Variable-length Data Stage
    A control pipe may have a variable-length data phase in which the
    host requests more data than is contained in the specified data
    structure. When all of the data structure is returned to the host,
    the function should indicate that the Data stage is ended by
    returning a packet that is shorter than the MaxPacketSize for the
    pipe. If the data structure is an exact multiple of wMaxPacketSize
    for the pipe, the function will return a zero-length packet to indicate
    the end of the Data stage.

In Case-A mentioned above:
If we disable software ZLP generation & ZLT=0 for endpoint 0 OR if software
ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
enumeration doesn't block for 6 seconds.

In Case-B mentioned above:
If we disable software ZLP generation & ZLT=0 for endpoint then enumeration
still blocks due to ZLP automatically generated by hardware and host not needing
it. But if we keep software ZLP generation enabled but we set ZLT=1 for
endpoint 0 then enumeration doesn't block for 6 seconds.

So the proper solution for this issue seems to disable automatic ZLP generation
by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
handle the ZLP generation based on req->zero field.

Signed-off-by: Abbas Raza <Abbas_Raza@mentor.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>