Re: [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings

On Thu, 14 Feb 2019 at 12:08, Roger Quadros wrote: > The beagleboard community is a primary user of this driver and we need to > find a solution so that PRUSS is usable either via remoteproc or via UIO. While being able to switch drivers without changing the DT by forcibly binding a different

[PATCH] pty: fix O_CLOEXEC for TIOCGPTPEER

It was being ignored because the flags were not passed to fd allocation. Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") Signed-off-by: Matthijs van Duin --- drivers/tty/pty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/pty.c b/drivers/tty/p

[PATCH] pty: fix O_CLOEXEC for TIOCGPTPEER

It was being ignored because the flags were not passed to fd allocation. Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") Signed-off-by: Matthijs van Duin --- drivers/tty/pty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/pty.c b/drivers/tty/p

Re: [PATCH 3.18 00/39] 3.18.53-stable review

On Thu, May 11, 2017 at 02:16:07PM -0700, Guenter Roeck wrote: > arch/arm/mach-omap2/omap-headsmp.S:60: Error: bad instruction `badr > r0,hyp_boot' > > I see "badr" used in later kernels, but not in v3.18. Does this possibly > require some secondary patches ? It was introduced in kernel 4.2 by

Re: [PATCH 3.18 00/39] 3.18.53-stable review

On Thu, May 11, 2017 at 02:16:07PM -0700, Guenter Roeck wrote: > arch/arm/mach-omap2/omap-headsmp.S:60: Error: bad instruction `badr > r0,hyp_boot' > > I see "badr" used in later kernels, but not in v3.18. Does this possibly > require some secondary patches ? It was introduced in kernel 4.2 by

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

on to use separate master-only and slave-only peripherals on the same bus just to avoid the horrible race conditions: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1990938#1990938 On 14 October 2016 at 10:57, Ravikumar <r...@ti.com> wrote: > > On Monday 29 August 2016 09:13

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

nly and slave-only peripherals on the same bus just to avoid the horrible race conditions: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1990938#1990938 On 14 October 2016 at 10:57, Ravikumar wrote: > > On Monday 29 August 2016 09:13 AM, Matthijs van Duin wrote: >> its irq

Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states

On 12 September 2016 at 15:35, Tom Rini wrote: > What do you mean by "you can't put it to good use" ? Is that the case > of stuff that's say exposed via a header and could be used but isn't (ie > the cape/hat/chip/etc case) or the IP block is still OK but just not > exposed

Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states

On 12 September 2016 at 15:35, Tom Rini wrote: > What do you mean by "you can't put it to good use" ? Is that the case > of stuff that's say exposed via a header and could be used but isn't (ie > the cape/hat/chip/etc case) or the IP block is still OK but just not > exposed at all? > > What

Re: L3 error handling (was: Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request..")

On Sat, Sep 10, 2016 at 04:46:49PM +0200, Matthijs van Duin wrote: > It probably doesn't help that the L3 interconnect registers on the > am335x aren't documented in the TRM. See below for its list of > components, target IDs, address mapping, and L3 error irq routing > (obtain

Re: L3 error handling (was: Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request..")

On Sat, Sep 10, 2016 at 04:46:49PM +0200, Matthijs van Duin wrote: > It probably doesn't help that the L3 interconnect registers on the > am335x aren't documented in the TRM. See below for its list of > components, target IDs, address mapping, and L3 error irq routing > (obtain

L3 error handling (was: Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request..")

On 10 September 2016 at 15:10, Tony Lindgren wrote: > Yeah I don't think we have L3 interrupts working for am335x. It probably doesn't help that the L3 interconnect registers on the am335x aren't documented in the TRM. See below for its list of components, target IDs, address

L3 error handling (was: Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request..")

On 10 September 2016 at 15:10, Tony Lindgren wrote: > Yeah I don't think we have L3 interrupts working for am335x. It probably doesn't help that the L3 interconnect registers on the am335x aren't documented in the TRM. See below for its list of components, target IDs, address mapping, and L3

Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz

On 10 September 2016 at 09:08, H. Nikolaus Schaller wrote: > Reducing the PWM frequency is good by itself since it should not be > unnecessarily > fast and helps to make the PWM to "average current" translation more linear. > > The non-linear effect is that the PWM controlled

Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz

On 10 September 2016 at 09:08, H. Nikolaus Schaller wrote: > Reducing the PWM frequency is good by itself since it should not be > unnecessarily > fast and helps to make the PWM to "average current" translation more linear. > > The non-linear effect is that the PWM controlled DC/DC converter

Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz

On Mon, Sep 05, 2016 at 11:16:38AM +0200, H. Nikolaus Schaller wrote: > This helps to get 100% intensity closer to "always on". > > It compensates for an effect of dmtimer which at 100% still emits short > "off" impulses and the startup-time of the DC/DC converter makes > backlight intensity not

Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz

On Mon, Sep 05, 2016 at 11:16:38AM +0200, H. Nikolaus Schaller wrote: > This helps to get 100% intensity closer to "always on". > > It compensates for an effect of dmtimer which at 100% still emits short > "off" impulses and the startup-time of the DC/DC converter makes > backlight intensity not

Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states

On 8 September 2016 at 15:38, Rob Herring wrote: > Yes, in theory a device can go from disabled to okay, but that's > generally never been supported. Linux takes the simple approach of > "disabled" means ignore it. I think we'll see that change with > overlays. No need for

Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states

On 8 September 2016 at 15:38, Rob Herring wrote: > Yes, in theory a device can go from disabled to okay, but that's > generally never been supported. Linux takes the simple approach of > "disabled" means ignore it. I think we'll see that change with > overlays. No need for future tense there,

Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request.."

On 10 September 2016 at 01:47, Tony Lindgren wrote: > Yeah. Just disable omap_l3_smx/noc driver and you should see > a proper stack trace. With the L3 driver we're seeing the trace > for L3 error interrupt. Huh what, I see a proper stack trace in his post? I'm pretty sure

Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request.."

On 10 September 2016 at 01:47, Tony Lindgren wrote: > Yeah. Just disable omap_l3_smx/noc driver and you should see > a proper stack trace. With the L3 driver we're seeing the trace > for L3 error interrupt. Huh what, I see a proper stack trace in his post? I'm pretty sure omap_l3_noc doesn't

Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request.."

If you look more carefully the first problem is actually a bus error: [ 15.776190] Unhandled fault: external abort on non-linefetch (0x1028) at 0xf9e3e044 [ 15.825925] PC is at omap_hwmod_read+0x14/0x28 [ 15.830583] LR is at omap_rtc_wait_not_busy+0x1c/0x44 I have no idea how the kernel manages

Re: [4.8.0-rc1] am335x-evm boot failure: n_tty_receive_buf_common: "Unable to handle kernel paging request.."

If you look more carefully the first problem is actually a bus error: [ 15.776190] Unhandled fault: external abort on non-linefetch (0x1028) at 0xf9e3e044 [ 15.825925] PC is at omap_hwmod_read+0x14/0x28 [ 15.830583] LR is at omap_rtc_wait_not_busy+0x1c/0x44 I have no idea how the kernel manages

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

On 28 August 2016 at 07:35, Wolfram Sang wrote: > Well, I2C is simple, what could go wrong? :/ Actually I2C is elegant and *seems* simple, but in all its asynchronicity there are actually a surprising number of fine details you can trip over. Maybe that's why so many i2c

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

On 28 August 2016 at 07:35, Wolfram Sang wrote: > Well, I2C is simple, what could go wrong? :/ Actually I2C is elegant and *seems* simple, but in all its asynchronicity there are actually a surprising number of fine details you can trip over. Maybe that's why so many i2c controllers suck: since

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

On 27 August 2016 at 19:22, Wolfram Sang wrote: > Uh, that sounds like bad HW... Making a mess of I2C controllers seems to be a popular hobby among chip designers :P ( I also really like how the RPi handles clock stretching... *cough* ) > While it surely is nice to have

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

On 27 August 2016 at 19:22, Wolfram Sang wrote: > Uh, that sounds like bad HW... Making a mess of I2C controllers seems to be a popular hobby among chip designers :P ( I also really like how the RPi handles clock stretching... *cough* ) > While it surely is nice to have super detailed

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

Greetings, unfortunate souls trying to use the omap-i2c peripheral in slave mode! :-) I recently posted some stuff about exactly that topic on TI's E2E forum, you may want to read this warning: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1955843#1955843 and post contains suggestions

Re: [RFC 1/1] drivers: i2c: omap: Add slave support

Greetings, unfortunate souls trying to use the omap-i2c peripheral in slave mode! :-) I recently posted some stuff about exactly that topic on TI's E2E forum, you may want to read this warning: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/514961/1955843#1955843 and post contains suggestions

Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

> [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port@1/endpoint > [8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss]) I can confirm that reverting 2ab9f5879162 fixes this regression, tested on omap5-uevm. Matthijs

Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

> [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port@1/endpoint > [8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss]) I can confirm that reverting 2ab9f5879162 fixes this regression, tested on omap5-uevm. Matthijs

Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

To clarify, this patch effectively reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle except it leaves behind unnecessary verbiage that this commit introduced. And to be clear, that commit *should* indeed be

Re: [PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

To clarify, this patch effectively reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle except it leaves behind unnecessary verbiage that this commit introduced. And to be clear, that commit *should* indeed be

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

On 13 January 2016 at 19:18, Nishanth Menon wrote: > As you already see it is ridiculously round about way of protecting RTC > time.. but anyways, for what ever reason, that was mandatory function to > support on certain product lines. Having secure date/time is probably necessary

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

On 13 January 2016 at 19:18, Nishanth Menon wrote: > As you already see it is ridiculously round about way of protecting RTC > time.. but anyways, for what ever reason, that was mandatory function to > support on certain product lines. Having secure date/time is probably necessary for some

Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency

On 3 May 2016 at 18:43, Tony Lindgren wrote: > Does a fixed divider calculation of input * (32768 / 27e6) make sense > here too as pointed out earlier by Matthijs for the ti81xx? That was an actual fractional divider, i.e. the output clock would be exactly that ratio of the

Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency

On 3 May 2016 at 18:43, Tony Lindgren wrote: > Does a fixed divider calculation of input * (32768 / 27e6) make sense > here too as pointed out earlier by Matthijs for the ti81xx? That was an actual fractional divider, i.e. the output clock would be exactly that ratio of the input clock, which

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

On 2 December 2015 at 01:46, Tony Lindgren wrote: > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? I'm in general no fan of such macros: it feels really awkward to have to make that distinction in dts when doing pin config. Note that if you're

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

On 2 December 2015 at 01:46, Tony Lindgren wrote: > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? Can't we just keep bit 18 out of the function mask? The bootloader should already have made sure all pins have bit 18 set (and bit 19 set to

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

On 2 December 2015 at 00:38, Tony Lindgren wrote: > - pinctrl-single,function-mask = > <0x300ff>; > + pinctrl-single,function-mask = > <0x707ff>; Reminder that silicon revision 2.1 and older require input enabled (bit

Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx

On 2 December 2015 at 00:38, Tony Lindgren wrote: > Looks like GPIO softreset status bit on both dm8168 and dm8148 > is broken and only goes high initially. After writing to sysc > softreset bit, the resetdone bit never goes high again. The resetdone bit works fine, but it needs all clocks

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

On 2 December 2015 at 00:38, Tony Lindgren wrote: > - pinctrl-single,function-mask = > <0x300ff>; > + pinctrl-single,function-mask = > <0x707ff>; Reminder that silicon revision 2.1 and older require

Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx

On 2 December 2015 at 00:38, Tony Lindgren wrote: > Looks like GPIO softreset status bit on both dm8168 and dm8148 > is broken and only goes high initially. After writing to sysc > softreset bit, the resetdone bit never goes high again. The resetdone bit works fine, but it

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

On 2 December 2015 at 01:46, Tony Lindgren wrote: > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? Can't we just keep bit 18 out of the function mask? The bootloader should already have made sure all pins have bit 18 set

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

On 2 December 2015 at 01:46, Tony Lindgren wrote: > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > dts macros that ensure that? I'm in general no fan of such macros: it feels really awkward to have to make that distinction in dts when doing pin config.

Re: [PATCH v3] crypto: omap-aes: Add support for GCM mode

On 15 September 2015 at 15:28, Lokesh Vutla wrote: > --- a/drivers/crypto/Kconfig > +++ b/drivers/crypto/Kconfig > @@ -293,6 +293,7 @@ config CRYPTO_DEV_OMAP_AES > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP2PLUS > select CRYPTO_AES > select CRYPTO_BLKCIPHER > +

Re: [PATCH v3] crypto: omap-aes: Add support for GCM mode

On 15 September 2015 at 15:28, Lokesh Vutla wrote: > --- a/drivers/crypto/Kconfig > +++ b/drivers/crypto/Kconfig > @@ -293,6 +293,7 @@ config CRYPTO_DEV_OMAP_AES > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP2PLUS > select CRYPTO_AES > select

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 1 June 2015 at 22:52, Tony Lindgren wrote: > OK that must be the case I've seen then. Probably that happens > when a device is not clocked. It happens for any interconnect error reported as a result of instruction fetch, but that is itself not a very common occurrence and obviously doesn't

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 1 June 2015 at 19:58, Tony Lindgren wrote: > I think these kernels are missing the configuration for l3-noc > driver? Yup. Since I'm pretty sure I have all the necessary info I was hoping look into that... somewhere in my copious spare time... > I tried it on omap4 that has l3-noc

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 1 June 2015 at 19:58, Tony Lindgren t...@atomide.com wrote: I think these kernels are missing the configuration for l3-noc driver? Yup. Since I'm pretty sure I have all the necessary info I was hoping look into that... somewhere in my copious spare time... I tried it on omap4 that has

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 1 June 2015 at 22:52, Tony Lindgren t...@atomide.com wrote: OK that must be the case I've seen then. Probably that happens when a device is not clocked. It happens for any interconnect error reported as a result of instruction fetch, but that is itself not a very common occurrence and

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 29 May 2015 at 17:50, Tony Lindgren wrote: > I believe some TI kernels use strongly-ordered mappings, mainline > kernel does not. Which kernel version are you using? Normally I periodically rebuild based on Robert C Nelson's -bone kernel (but with heavily customized config). I also tried a

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 29 May 2015 at 17:50, Tony Lindgren t...@atomide.com wrote: I believe some TI kernels use strongly-ordered mappings, mainline kernel does not. Which kernel version are you using? Normally I periodically rebuild based on Robert C Nelson's -bone kernel (but with heavily customized config). I

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 29 May 2015 at 02:58, Matthijs van Duin wrote: > It is only guaranteed to happen immediately (before the next > instruction is executed) if the error occurs before the posting-point > of the write. However, in that case the error is reported in-band to > the cpu, resulting in a

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 29 May 2015 at 00:24, Tony Lindgren wrote: > Hmm I believe the interrupt happens immediately trying to access an > invalid device. But maybe I'm thinking about just errors if a device > is not powered or clocked. It is only guaranteed to happen immediately (before the next instruction is

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 28 May 2015 at 18:01, Tony Lindgren wrote: > For failed device access you get an interrupt Well for failed reads you get a bus error, and "catching" those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 28 May 2015 at 18:01, Tony Lindgren t...@atomide.com wrote: For failed device access you get an interrupt Well for failed reads you get a bus error, and catching those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it,

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 29 May 2015 at 02:58, Matthijs van Duin matthijsvand...@gmail.com wrote: It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting

Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

On 29 May 2015 at 00:24, Tony Lindgren t...@atomide.com wrote: Hmm I believe the interrupt happens immediately trying to access an invalid device. But maybe I'm thinking about just errors if a device is not powered or clocked. It is only guaranteed to happen immediately (before the next

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 17 March 2015 at 03:19, Tony Lindgren wrote: > Yes so it seem here too, this is dm816x rev c, what do you have? jtag ID reads 0x1b81e02f, so that would be rev 1.1 / rev A. > Anyways, I'll add a note that at least rev c does not seems to do > anything with USB_CTRL but that we follow what the

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 17 March 2015 at 03:19, Tony Lindgren t...@atomide.com wrote: Yes so it seem here too, this is dm816x rev c, what do you have? jtag ID reads 0x1b81e02f, so that would be rev 1.1 / rev A. Anyways, I'll add a note that at least rev c does not seems to do anything with USB_CTRL but that we

Re: [PATCH] phy: Add a driver for dm816x USB PHY

s SATA -- Primus doesn't). Matthijs On 16 March 2015 at 17:49, Tony Lindgren wrote: > * Matthijs van Duin [150314 14:04]: >> On 13 March 2015 at 20:30, Tony Lindgren wrote: >> > Hmm OK have to check that. It could also be that dm816x documentation >> > is copy

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 16 March 2015 at 17:49, Tony Lindgren t...@atomide.com wrote: * Matthijs van Duin matthijsvand...@gmail.com [150314 14:04]: On 13 March 2015 at 20:30, Tony Lindgren t...@atomide.com wrote: Hmm OK have to check that. It could also be that dm816x documentation is copy-paste from da850

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 13 March 2015 at 20:30, Tony Lindgren wrote: > Hmm OK have to check that. It could also be that dm816x documentation > is copy-paste from da850 or am3517 and the PHY got changed in the > hardware as the registers don't match the documentation. Only the > dm816x errata has right documentation

Re: [PATCH] phy: Add a driver for dm816x USB PHY

On 13 March 2015 at 20:30, Tony Lindgren t...@atomide.com wrote: Hmm OK have to check that. It could also be that dm816x documentation is copy-paste from da850 or am3517 and the PHY got changed in the hardware as the registers don't match the documentation. Only the dm816x errata has right

Re: [PATCH] phy: Add a driver for dm816x USB PHY

Given that the documentation mentions the actual phy used, it may be worth mentioning this also in the driver? i.e. that it's not a "dm816x phy" but a "SR70LX Synopsys USB 2.0 OTG nanoPHY" (in contrast to the dm814x and am335x which use a phy TI made themselves) USB is one of the few subsystems

Re: [PATCH] phy: Add a driver for dm816x USB PHY

Given that the documentation mentions the actual phy used, it may be worth mentioning this also in the driver? i.e. that it's not a dm816x phy but a SR70LX Synopsys USB 2.0 OTG nanoPHY (in contrast to the dm814x and am335x which use a phy TI made themselves) USB is one of the few subsystems of