Changing the frequency of the USB clock must be done before the
PLL is powered on (prepared). This matters when the USB clock
is not setup by either boot ROM or boot loader. Reorder the
function calls to adhere to the order noted in the user manual.
Signed-off-by: Joachim Eastwood
---
Hi Kishon
On 15 July 2015 at 12:50, Kishon Vijay Abraham I wrote:
>
>
> On Friday 10 July 2015 02:18 AM, Joachim Eastwood wrote:
>> This patch set adds support for the internal USB OTG PHY found
>> on NXP LPC18xx and LPC43xx devices. Driver takes care of
>> enabling the PHY and s
Add binding documentation for NXP LPC18xx/43xx USB OTG PHY. This
PHY can found on NXP LPC18xx and LPC43xx devices with USB support.
Signed-off-by: Joachim Eastwood
---
.../bindings/phy/phy-lpc18xx-usb-otg.txt | 26 ++
1 file changed, 26 insertions(+)
create mode
set on 4.2-rc1.
Changes in v4:
- rebase on 4.2-rc1
- move dt node under creg where the control reg is
Changes in v3:
- depend on MFD_SYSCON
Changes in v2:
- use PTR_ERR_OR_ZERO in phy driver
- rename binding doc
- update doc commit message
Joachim Eastwood (2):
phy: add lpc18xx usb otg
Add PHY driver for the internal USB OTG PHY found on NXP
LPC18xx and LPC43xx devices. This driver takes care of
enabling the PHY in CREG (syscon) and setting the required
clock frequency.
Signed-off-by: Joachim Eastwood
---
drivers/phy/Kconfig | 11 +++
drivers/phy/Makefile
pen_hook/atmel_open_close assignment is dropped, these
global variables will be useless so we should remove them as well.
There are also some other code that uses the variables that can be
dropped. Should shave another 22 lines of code off atmel_serial.c
I can send out a patch on top of yours if yo
.h"
The at91_ether driver in net-next does not need to be change since it
all mach includes has already been removed by other patches and it
includes linux/platform_data/macb.h directly.
What tree was these patches based on?
The at91_ether driver changes has been in linux-next for
number of
ports) started setting unused pins to EINVAL. But this exposed a bug in the
ohci_hcd_at91_overcurrent_irq function where the gpio was used without being
checked to see if it is valid.
This patches fixed the issue by adding the gpio valid check.
Signed-off-by: Joachim Eastwood
---
Note: I
registered, assigned
bus number 1
[8.34] at91_ohci at91_ohci: irq 39, io mem 0x0030
[8.52] hub 1-0:1.0: USB hub found
[8.66] hub 1-0:1.0: 1 port detected
I assume this commit tried to fix the "can't request overcurrent gpio
0" message.
I am runni