davinci_emac failures in 4.18-rc1 on AM3517-EVM

2018-06-19 Thread Adam Ford 
I am not sure if anyone else has seen this.  If not, I'll bisect, but
the AM3517 ethernet seems to have died, and it's throwing some errors

[2.708933] davinci_mdio davinci_mdio.0: failed to get device clock
[2.715363] davinci_mdio: probe of davinci_mdio.0 failed with error -2

[snip]

[3.054552] davinci_emac davinci_emac.0: failed to get EMAC clock
[3.061195] davinci_emac: probe of davinci_emac.0 failed with error -16


If no one has seen this, I'll look into it, but I didn't want to waste
time if someone is already aware of it.

adam

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-10-28 Thread Adam Ford 
On Fri, Oct 27, 2017 at 5:55 AM, Adam Ford <aford...@gmail.com> wrote:
> On Tue, May 9, 2017 at 9:14 AM, Rob Herring <r...@kernel.org> wrote:
>> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <bar...@tkos.co.il> wrote:
>>> Hi Rob,
>>>
>>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford...@gmail.com> wrote:
>>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <s...@kernel.org> 
>>>> > wrote:
>>>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <r...@kernel.org> wrote:
>>>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>>> >>> > modules and enables support on HiKey board with with the WL1835 
>>>> >>> > module.
>>>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>>> >>>
>>>> >>> Without UIM daemon, what instruction do you use to load the BT 
>>>> >>> firmware?
>>>> >>>
>>>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>>> >>> might have some insight.
>>>> >>>
>>>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 300 flow  Just
>>>> >>> returns a timeout.
>>>> >>>
>>>> >>> I modified my i.MX6 device tree per the binding documentation and
>>>> >>> setup the regulators and enable GPIO pins.
>>>> >>
>>>> >> If you configured everything correctly no userspace interaction is
>>>> >> required. The driver should request the firmware automatically once
>>>> >> you power up the bluetooth device.
>>>> >>
>>>> >> Apart from DT changes make sure, that the following options are
>>>> >> enabled and check dmesg for any hints.
>>>> >>
>>>> >> CONFIG_SERIAL_DEV_BUS
>>>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>>>> >> CONFIG_BT_HCIUART
>>>> >> CONFIG_BT_HCIUART_LL
>>>> >
>>>> > I have enabled those flags, and I have updated my device tree.
>>>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>>>> > getting a lot of timeout errors.  I tested this against the original
>>>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>>>> > the btwilink driver.
>>>> >
>>>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>>>> > am obviously missing something.
>>>> >
>>>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>>>> > (-110)
>>>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>>>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>>>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>>>> > (-110)
>>>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>>>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>>>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>>>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>>>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>>>> > [   69.153533] Bluetooth: Data length is too large
>>>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>>>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>>>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>>>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>>>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>>>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>>>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed 
>>>> > (-110)
>>>>
>>>> There's a bug in serdev_device_write(), so if you have that function
>>>> you need either the fix I sent or the patch to make
>>>> serdev_device_writebuf atomic again. Both are on the linux-serial
>>>> list, but not in any tree yet.
>>>
>>> You refer to the patches below, right?
>>>
>>>   [PATC

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-10-27 Thread Adam Ford 
On Tue, May 9, 2017 at 9:14 AM, Rob Herring <r...@kernel.org> wrote:
> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <bar...@tkos.co.il> wrote:
>> Hi Rob,
>>
>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford...@gmail.com> wrote:
>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <s...@kernel.org> 
>>> > wrote:
>>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <r...@kernel.org> wrote:
>>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>> >>> > modules and enables support on HiKey board with with the WL1835 
>>> >>> > module.
>>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>> >>>
>>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>> >>>
>>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>> >>> might have some insight.
>>> >>>
>>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 300 flow  Just
>>> >>> returns a timeout.
>>> >>>
>>> >>> I modified my i.MX6 device tree per the binding documentation and
>>> >>> setup the regulators and enable GPIO pins.
>>> >>
>>> >> If you configured everything correctly no userspace interaction is
>>> >> required. The driver should request the firmware automatically once
>>> >> you power up the bluetooth device.
>>> >>
>>> >> Apart from DT changes make sure, that the following options are
>>> >> enabled and check dmesg for any hints.
>>> >>
>>> >> CONFIG_SERIAL_DEV_BUS
>>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>>> >> CONFIG_BT_HCIUART
>>> >> CONFIG_BT_HCIUART_LL
>>> >
>>> > I have enabled those flags, and I have updated my device tree.
>>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>>> > getting a lot of timeout errors.  I tested this against the original
>>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>>> > the btwilink driver.
>>> >
>>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>>> > am obviously missing something.
>>> >
>>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>>> > [   69.153533] Bluetooth: Data length is too large
>>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed 
>>> > (-110)
>>>
>>> There's a bug in serdev_device_write(), so if you have that function
>>> you need either the fix I sent or the patch to make
>>> serdev_device_writebuf atomic again. Both are on the linux-serial
>>> list, but not in any tree yet.
>>
>> You refer to the patches below, right?
>>
>>   [PATCH] tty: serdev: fix serdev_device_write return value,
>>   http://www.spinics.net/lists/linux-serial/msg26117.html
>>
>>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>>   http://www.spinics.net/lists/linux-serial/msg26113.html
>
> Yes, either one will fix the issue.

I am finally getting back to testing these on my DM3730 board, since
it appears most of the

Re: Fwd: DA850-evm MAC Address is random

2017-09-08 Thread Adam Ford 
On Thu, Sep 7, 2017 at 3:36 AM, Sekhar Nori <nsek...@ti.com> wrote:
> On Thursday 07 September 2017 03:11 AM, Adam Ford wrote:
>> On Mon, Sep 4, 2017 at 11:42 PM, Sekhar Nori <nsek...@ti.com> wrote:
>>> Hi Adam,
>>>
>>> On Wednesday 30 August 2017 11:08 AM, Sekhar Nori wrote:
>>>>> I wonder if U-Boot isn't pushing something to Linux because it doesn't
>>>>> appear to be running some of the da850 specific code even when I run
>>>>> linux-next.  Can you tell me what verision of U-Boot you're using?
>>>>> Other than using davinci_all_defconfig, did you change the
>>>>> configuration at all?
>>>
>>>> I am using U-Boot 2017.01. Yes, the kernel was built using
>>>> davinci_all_defconfig and no other config change. Before booting kernel,
>>>> can you confirm that ethaddr is set in U-Boot environment? This is what
>>>> fdt_fixup_ethernet() reads to fixup the FDT before boot.
>>>>
>>>> Here is my complete boot log with environment variable dump.
>>>>
>>>> http://pastebin.ubuntu.com/25430265/
>>>
>>> Were you able to get rid of the random mac address problem?
>>
>> Not yet.  I haven't been able to rebuild Arago using TI's instructions
>> on the Wiki.  I am not sure if it's a dependency issue or something
>> else.  When I run Linux 4.13 using Buildroot as the rootfs, it does
>> not appear to run da850_evm_m25p80_notify_add().  I am going to
>> investigate whether or not da850_evm_init() is getting called.  I was
>> wondering if you had some insight as to what calls that function?  It
>> looks like it's defined as part of MACHINE_START(DAVINCI_DA850_EVM,
>> "DaVinci DA850/OMAP-L138/AM18x EVM"), but I don't know how it gets
>> called.
>
> These functions are called only when booting using the legacy board file
> method. From your logs before, you are booting using device tree. So
> these functions are irrelevant.

Ok. That makes a lot more sense now.  I was really confused why the functions
were not getting called.

> Can you check if the mac address has been populated in the device-tree
> by dumping it from /proc/device-tree/.../local-mac-address? That will
> tell us if U-Boot is updating the mac address or not.

It does not appear to getting called.

# hexdump ./soc@1c0/ethernet@22/local-mac-address
000   
006
#

I'll work on something that pulls in the MAC address then inserts it
into the device tree like the recommendation that Tony made.

Thanks for all your help.

adam
>
> Thanks,
> Sekhar

Re: Fwd: DA850-evm MAC Address is random

2017-09-06 Thread Adam Ford 
On Mon, Sep 4, 2017 at 11:42 PM, Sekhar Nori  wrote:
> Hi Adam,
>
> On Wednesday 30 August 2017 11:08 AM, Sekhar Nori wrote:
>>> I wonder if U-Boot isn't pushing something to Linux because it doesn't
>>> appear to be running some of the da850 specific code even when I run
>>> linux-next.  Can you tell me what verision of U-Boot you're using?
>>> Other than using davinci_all_defconfig, did you change the
>>> configuration at all?
>
>> I am using U-Boot 2017.01. Yes, the kernel was built using
>> davinci_all_defconfig and no other config change. Before booting kernel,
>> can you confirm that ethaddr is set in U-Boot environment? This is what
>> fdt_fixup_ethernet() reads to fixup the FDT before boot.
>>
>> Here is my complete boot log with environment variable dump.
>>
>> http://pastebin.ubuntu.com/25430265/
>
> Were you able to get rid of the random mac address problem?

Not yet.  I haven't been able to rebuild Arago using TI's instructions
on the Wiki.  I am not sure if it's a dependency issue or something
else.  When I run Linux 4.13 using Buildroot as the rootfs, it does
not appear to run da850_evm_m25p80_notify_add().  I am going to
investigate whether or not da850_evm_init() is getting called.  I was
wondering if you had some insight as to what calls that function?  It
looks like it's defined as part of MACHINE_START(DAVINCI_DA850_EVM,
"DaVinci DA850/OMAP-L138/AM18x EVM"), but I don't know how it gets
called.

thanks

adam
>
> Thanks,
> Sekhar

Re: Fwd: DA850-evm MAC Address is random

2017-08-29 Thread Adam Ford 
On Tue, Aug 29, 2017 at 10:20 AM, Adam Ford <aford...@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 10:16 AM, Sekhar Nori <nsek...@ti.com> wrote:
>> On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
>>> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsek...@ti.com> wrote:
>>>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsek...@ti.com> wrote:
>>>>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>>>>> * Adam Ford <aford...@gmail.com> [170828 13:33]:
>>>>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>>>>> <grygorii.stras...@ti.com> wrote:
>>>>>>>>> Cc: Sekhar
>>>>>>>>>
>>>>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>>>>
>>>>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>>>>
>>>>>>>>>> The function appears to lookup varions boards using
>>>>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>>>>> am4372 and dra7.  I don't see the ti,davinci-dm6467-emac which is
>>>>>>>>>> what's shown in the da850 device tree.
>>>>>>>>>>
>>>>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not sure if MAC address can be read from Control module.
>>>>>>>>> May be Sekhar can say more?
>>>>>>>>
>>>>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>>>>> into the SPI flash.  The Bootloader reads this from either SPI or its
>>>>>>>> env variables.  Looking at the partition info listed in the
>>>>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>>>>> Unfortunately, I don't see any code that reads it out.  I was hoping
>>>>>>
>>>>>> This code is present in U-Boot sources at
>>>>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>>>>> its usage in misc_init_r().
>>>>>>
>>>>>>>> there might be a way to just pass cmdline parameter from the
>>>>>>>> bootloader to the kernel to accept the MAC address.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> "local-mac-address" dt porp
>>>>>>>>
>>>>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>>>>> device tree.
>>>>>>>
>>>>>>> That piece of code exists somewhere in u-boot already. Note how
>>>>>>
>>>>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>>>>
>>>>>>> we are populating the mac address for USB Ethernet drivers in
>>>>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>>>>> the device tree") for some more information.
>>>>>>>
>>>>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>>>>
>>>>>> That's exactly what was missing. I have sent a patch for fixing that and
>>>>>> copied you there.
>>>>>
>>>>> Thanks for doing that.
>>>>>
>>>>>>
>>>>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>>>>&g

Re: Fwd: DA850-evm MAC Address is random

2017-08-29 Thread Adam Ford 
On Tue, Aug 29, 2017 at 10:16 AM, Sekhar Nori <nsek...@ti.com> wrote:
> On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsek...@ti.com> wrote:
>>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsek...@ti.com> wrote:
>>>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>>>> * Adam Ford <aford...@gmail.com> [170828 13:33]:
>>>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>>>> <grygorii.stras...@ti.com> wrote:
>>>>>>>> Cc: Sekhar
>>>>>>>>
>>>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>>>
>>>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>>>
>>>>>>>>> The function appears to lookup varions boards using
>>>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>>>> am4372 and dra7.  I don't see the ti,davinci-dm6467-emac which is
>>>>>>>>> what's shown in the da850 device tree.
>>>>>>>>>
>>>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>>>
>>>>>>>>
>>>>>>>> Not sure if MAC address can be read from Control module.
>>>>>>>> May be Sekhar can say more?
>>>>>>>
>>>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>>>> into the SPI flash.  The Bootloader reads this from either SPI or its
>>>>>>> env variables.  Looking at the partition info listed in the
>>>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>>>> Unfortunately, I don't see any code that reads it out.  I was hoping
>>>>>
>>>>> This code is present in U-Boot sources at
>>>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>>>> its usage in misc_init_r().
>>>>>
>>>>>>> there might be a way to just pass cmdline parameter from the
>>>>>>> bootloader to the kernel to accept the MAC address.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>>>
>>>>>>>>
>>>>>>>> "local-mac-address" dt porp
>>>>>>>
>>>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>>>> device tree.
>>>>>>
>>>>>> That piece of code exists somewhere in u-boot already. Note how
>>>>>
>>>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>>>
>>>>>> we are populating the mac address for USB Ethernet drivers in
>>>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>>>> the device tree") for some more information.
>>>>>>
>>>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>>>
>>>>> That's exactly what was missing. I have sent a patch for fixing that and
>>>>> copied you there.
>>>>
>>>> Thanks for doing that.
>>>>
>>>>>
>>>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>>>> v4.13 itself.
>>>>
>>>> I will test it.  Do need to run some instruction or do something
>>>> special in U-Boot to pass this in the proper place for the kernel to
>>>> pull it?  Tony's patch reference showed
>>>> command for fdt set, but I am not sure I fully understand the
>>>> parameters that went along with that.
>>>
>>> Nope, just applying the patch and booting the with the new dtb should
>>> result in the random mac address going away.
>>
>> Unfortunately, I am not seeing any change with the patch (at least
>> with Kernel 4.12.9 from stable).
>>
>> netconsole: network logging started
>> davinci_emac davinci_emac.1: incompatible machine/device type for
>> reading mac address
>> davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
>>
>> Looking at the source for cpsw-common.c function ti_cm_get_macid()
>> doesn't have a case for the  ti,davinci-dm6467-emac so I wonder if
>> there might be more to it.
>
> Hmm, it did solve the issue for me when I tried latest -next. And
> reverting the patch brought back the random mac address usage. Could you
> try latest mainline or -next?
>
> Meanwhile let me see whats going on with the observations you have.

I will try again with -next this afternoon and see what I can find.
Can you tell me which U-Boot version you're using? I want to match
your setup. I want to see if something is missing during the hand-off
between the Bootloader and Linux.


>
> Thanks,
> Sekhar

Re: Fwd: DA850-evm MAC Address is random

2017-08-29 Thread Adam Ford 
On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsek...@ti.com> wrote:
> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsek...@ti.com> wrote:
>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>> * Adam Ford <aford...@gmail.com> [170828 13:33]:
>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>> <grygorii.stras...@ti.com> wrote:
>>>>>> Cc: Sekhar
>>>>>>
>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>
>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>
>>>>>>> The function appears to lookup varions boards using
>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>> am4372 and dra7.  I don't see the ti,davinci-dm6467-emac which is
>>>>>>> what's shown in the da850 device tree.
>>>>>>>
>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>
>>>>>>
>>>>>> Not sure if MAC address can be read from Control module.
>>>>>> May be Sekhar can say more?
>>>>>
>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>> into the SPI flash.  The Bootloader reads this from either SPI or its
>>>>> env variables.  Looking at the partition info listed in the
>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>> Unfortunately, I don't see any code that reads it out.  I was hoping
>>>
>>> This code is present in U-Boot sources at
>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>> its usage in misc_init_r().
>>>
>>>>> there might be a way to just pass cmdline parameter from the
>>>>> bootloader to the kernel to accept the MAC address.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>
>>>>>>
>>>>>> "local-mac-address" dt porp
>>>>>
>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>> device tree.
>>>>
>>>> That piece of code exists somewhere in u-boot already. Note how
>>>
>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>
>>>> we are populating the mac address for USB Ethernet drivers in
>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>> the device tree") for some more information.
>>>>
>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>
>>> That's exactly what was missing. I have sent a patch for fixing that and
>>> copied you there.
>>
>> Thanks for doing that.
>>
>>>
>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>> v4.13 itself.
>>
>> I will test it.  Do need to run some instruction or do something
>> special in U-Boot to pass this in the proper place for the kernel to
>> pull it?  Tony's patch reference showed
>> command for fdt set, but I am not sure I fully understand the
>> parameters that went along with that.
>
> Nope, just applying the patch and booting the with the new dtb should
> result in the random mac address going away.

Unfortunately, I am not seeing any change with the patch (at least
with Kernel 4.12.9 from stable).

netconsole: network logging started
davinci_emac davinci_emac.1: incompatible machine/device type for
reading mac address
davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be

Looking at the source for cpsw-common.c function ti_cm_get_macid()
doesn't have a case for the  ti,davinci-dm6467-emac so I wonder if
there might be more to it.

adam

>
> Thanks,
> Sekhar

Re: Fwd: DA850-evm MAC Address is random

2017-08-29 Thread Adam Ford 
On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsek...@ti.com> wrote:
> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>> * Adam Ford <aford...@gmail.com> [170828 13:33]:
>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>> <grygorii.stras...@ti.com> wrote:
>>>> Cc: Sekhar
>>>>
>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>
>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>> reading mac address ' and then generates a random MAC address.
>>>>>
>>>>> The function appears to lookup varions boards using
>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>> am4372 and dra7.  I don't see the ti,davinci-dm6467-emac which is
>>>>> what's shown in the da850 device tree.
>>>>>
>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>
>>>>
>>>> Not sure if MAC address can be read from Control module.
>>>> May be Sekhar can say more?
>>>
>>> My understanding is that the MAC address is programmed by Logic PD
>>> into the SPI flash.  The Bootloader reads this from either SPI or its
>>> env variables.  Looking at the partition info listed in the
>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>> Unfortunately, I don't see any code that reads it out.  I was hoping
>
> This code is present in U-Boot sources at
> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
> its usage in misc_init_r().
>
>>> there might be a way to just pass cmdline parameter from the
>>> bootloader to the kernel to accept the MAC address.
>>>
>>>>
>>>>>
>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>> driver so it doesn't generate a random MAC?
>>>>
>>>>
>>>> "local-mac-address" dt porp
>>>
>>> The downside here, is that we'd have to have the Bootloader modify the
>>> device tree.
>>
>> That piece of code exists somewhere in u-boot already. Note how
>
> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>
>> we are populating the mac address for USB Ethernet drivers in
>> u-boot and then the Ethernet driver code parses it. See commit
>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>> the device tree") for some more information.
>>
>> I think u-boot needs the ethernet alias for finding the interface.
>
> That's exactly what was missing. I have sent a patch for fixing that and
> copied you there.

Thanks for doing that.

>
> Adam, if I can get your Tested-by, I will make an attempt to send it for
> v4.13 itself.

I will test it.  Do need to run some instruction or do something
special in U-Boot to pass this in the proper place for the kernel to
pull it?  Tony's patch reference showed
command for fdt set, but I am not sure I fully understand the
parameters that went along with that.

adam
>
> Thanks,
> Sekhar

Re: Fwd: DA850-evm MAC Address is random

2017-08-28 Thread Adam Ford 
On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
<grygorii.stras...@ti.com> wrote:
> Cc: Sekhar
>
> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>
>> The davinvi_emac MAC address seems to attempt a call to
>> ti_cm_get_macid in cpsw-common.c but it returns the message
>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>> reading mac address ' and then generates a random MAC address.
>>
>> The function appears to lookup varions boards using
>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>> am4372 and dra7.  I don't see the ti,davinci-dm6467-emac which is
>> what's shown in the da850 device tree.
>>
>> Is there a patch somewhere for supporting the da850-evm?
>
>
> Not sure if MAC address can be read from Control module.
> May be Sekhar can say more?

My understanding is that the MAC address is programmed by Logic PD
into the SPI flash.  The Bootloader reads this from either SPI or its
env variables.  Looking at the partition info listed in the
da850-evm.dts file, it appears as if they've reserved space for it.
Unfortunately, I don't see any code that reads it out.  I was hoping
there might be a way to just pass cmdline parameter from the
bootloader to the kernel to accept the MAC address.

>
>>
>> If not, is there a way to pass the MAC address from U-Boot to the
>> driver so it doesn't generate a random MAC?
>
>
> "local-mac-address" dt porp

The downside here, is that we'd have to have the Bootloader modify the
device tree.
>
> --
> regards,
> -grygorii

thanks

adam

Fwd: DA850-evm MAC Address is random

2017-08-28 Thread Adam Ford 
The davinvi_emac MAC address seems to attempt a call to
ti_cm_get_macid in cpsw-common.c but it returns the message
'davinci_emac davinci_emac.1: incompatible machine/device type for
reading mac address ' and then generates a random MAC address.

The function appears to lookup varions boards using
'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
am4372 and dra7.  I don't see the ti,davinci-dm6467-emac which is
what's shown in the da850 device tree.

Is there a patch somewhere for supporting the da850-evm?

If not, is there a way to pass the MAC address from U-Boot to the
driver so it doesn't generate a random MAC?

adam

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-05-05 Thread Adam Ford 
On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <s...@kernel.org> wrote:
> Hi,
>
> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <r...@kernel.org> wrote:
>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> > modules and enables support on HiKey board with with the WL1835 module.
>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>
>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>
>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>> might have some insight.
>>
>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 300 flow  Just
>> returns a timeout.
>>
>> I modified my i.MX6 device tree per the binding documentation and
>> setup the regulators and enable GPIO pins.
>
> If you configured everything correctly no userspace interaction is
> required. The driver should request the firmware automatically once
> you power up the bluetooth device.
>
> Apart from DT changes make sure, that the following options are
> enabled and check dmesg for any hints.
>
> CONFIG_SERIAL_DEV_BUS
> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> CONFIG_BT_HCIUART
> CONFIG_BT_HCIUART_LL
>


I have enabled those flags, and I have updated my device tree.
I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
getting a lot of timeout errors.  I tested this against the original
implemention I had in pdata-quirks.c using the ti-st driver, uim & and
the btwilink driver.

I pulled in some of the newer patches to enable the wl1283-st, but I
am obviously missing something.

I   58.717651] Bluetooth: hci0: Reading TI version information failed
(-110)
[   58.724853] Bluetooth: hci0: download firmware failed, retrying...
[   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
[   68.957641] Bluetooth: hci0: Reading TI version information failed
(-110)
[   68.964843] Bluetooth: hci0: download firmware failed, retrying...
[   69.132171] Bluetooth: Unknown HCI packet type 06
[   69.138244] Bluetooth: Unknown HCI packet type 0c
[   69.143249] Bluetooth: Unknown HCI packet type 40
[   69.148498] Bluetooth: Unknown HCI packet type 20
[   69.153533] Bluetooth: Data length is too large
[   69.158569] Bluetooth: Unknown HCI packet type a0
[   69.163574] Bluetooth: Unknown HCI packet type 00
[   69.168731] Bluetooth: Unknown HCI packet type 00
[   69.173736] Bluetooth: Unknown HCI packet type 34
[   69.178924] Bluetooth: Unknown HCI packet type 91
[   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
[   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)

Since the pdata-quirks and original ti-st drivers work together, I
know the hardware is fine.  The only change to the device tree is the
addition of the Bluetooth container:

bluetooth {
  compatible = "ti,wl1283-st";
  enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
};

Any thoughts or suggestions to try?  I get similar behavior on an
i.MX6 board with a wl1837-st module as well.

adam
> -- Sebastian

Re: [PATCH 0/4] TI Bluetooth serdev support

2017-04-30 Thread Adam Ford 
On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring  wrote:
> This series adds serdev support to the HCI LL protocol used on TI BT
> modules and enables support on HiKey board with with the WL1835 module.
> With this the custom TI UIM daemon and btattach are no longer needed.

Without UIM daemon, what instruction do you use to load the BT firmware?

I was thinking 'hciattach' but I was having trouble.  I was hoping you
might have some insight.

 hciattach -t 30 -s 115200 /dev/ttymxc1 texas 300 flow  Just
returns a timeout.

I modified my i.MX6 device tree per the binding documentation and
setup the regulators and enable GPIO pins.

adam
>
> The series is available on this git branch[1]. Patch 2 is just clean-up
> and can be applied independently. Patch 3 is dependent on the series
> "Nokia H4+ support". I'd suggest both series are merged thru the BT tree.
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth
>
> Rob Herring (4):
>   dt-bindings: net: Add TI WiLink shared transport binding
>   bluetooth: hci_uart: remove unused hci_uart_init_tty
>   bluetooth: hci_uart: add LL protocol serdev driver support
>   arm64: dts: hikey: add WL1835 Bluetooth device node
>
>  .../devicetree/bindings/net/ti,wilink-st.txt   |  35 +++
>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   5 +
>  drivers/bluetooth/hci_ldisc.c  |  19 --
>  drivers/bluetooth/hci_ll.c | 261 
> -
>  drivers/bluetooth/hci_uart.h   |   1 -
>  5 files changed, 300 insertions(+), 21 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> --
> 2.10.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 3/4] bluetooth: hci_uart: add LL protocol serdev driver support

2017-04-17 Thread Adam Ford 
On Thu, Apr 13, 2017 at 10:03 AM, Rob Herring  wrote:
> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
>
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.

I am using pdata-quirks to drive my wl1283 Bluetooth on a DM3730.  I
have the Bluetooth set to 300 baud in pdata quirks.  Looking at
the binding, I don't see an option to set the baudrate.  Is there (or
will there) be a way to set the baud rate of the Bluetooth?

adam
>
> Signed-off-by: Rob Herring 
> Cc: Marcel Holtmann 
> Cc: Gustavo Padovan 
> Cc: Johan Hedberg 
> Cc: linux-blueto...@vger.kernel.org
> ---
> v3:
> - rebase on bluetooth-next
> - Add explicit of.h include
> v2:
> - Use IS_ENABLED() to fix module build
>
>  drivers/bluetooth/hci_ll.c | 262 
> -
>  1 file changed, 261 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 02692fe30279..485e8eb04542 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -34,20 +34,24 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> +#include 
>
>  #include "hci_uart.h"
>
> @@ -76,6 +80,12 @@ struct hcill_cmd {
> u8 cmd;
>  } __packed;
>
> +struct ll_device {
> +   struct hci_uart hu;
> +   struct serdev_device *serdev;
> +   struct gpio_desc *enable_gpio;
> +};
> +
>  struct ll_struct {
> unsigned long rx_state;
> unsigned long rx_count;
> @@ -136,6 +146,9 @@ static int ll_open(struct hci_uart *hu)
>
> hu->priv = ll;
>
> +   if (hu->serdev)
> +   serdev_device_open(hu->serdev);
> +
> return 0;
>  }
>
> @@ -164,6 +177,13 @@ static int ll_close(struct hci_uart *hu)
>
> kfree_skb(ll->rx_skb);
>
> +   if (hu->serdev) {
> +   struct ll_device *lldev = 
> serdev_device_get_drvdata(hu->serdev);
> +   gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +
> +   serdev_device_close(hu->serdev);
> +   }
> +
> hu->priv = NULL;
>
> kfree(ll);
> @@ -505,9 +525,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
> return skb_dequeue(>txq);
>  }
>
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
> +static int read_local_version(struct hci_dev *hdev)
> +{
> +   int err = 0;
> +   unsigned short version = 0;
> +   struct sk_buff *skb;
> +   struct hci_rp_read_local_version *ver;
> +
> +   skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, 
> HCI_INIT_TIMEOUT);
> +   if (IS_ERR(skb)) {
> +   bt_dev_err(hdev, "Reading TI version information failed 
> (%ld)",
> +  PTR_ERR(skb));
> +   err = PTR_ERR(skb);
> +   goto out;
> +   }
> +   if (skb->len != sizeof(*ver)) {
> +   err = -EILSEQ;
> +   goto out;
> +   }
> +
> +   ver = (struct hci_rp_read_local_version *)skb->data;
> +   if (le16_to_cpu(ver->manufacturer) != 13) {
> +   err = -ENODEV;
> +   goto out;
> +   }
> +
> +   version = le16_to_cpu(ver->lmp_subver);
> +
> +out:
> +   if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
> +   kfree_skb(skb);
> +   return err ? err : version;
> +}
> +
> +/**
> + * download_firmware -
> + * internal function which parses through the .bts firmware
> + * script file intreprets SEND, DELAY actions only as of now
> + */
> +static int download_firmware(struct ll_device *lldev)
> +{
> +   unsigned short chip, min_ver, maj_ver;
> +   int version, err, len;
> +   unsigned char *ptr, *action_ptr;
> +   unsigned char bts_scr_name[40]; /* 40 char long bts scr name? */
> +   const struct firmware *fw;
> +   struct sk_buff *skb;
> +   struct hci_command *cmd;
> +
> +   version = read_local_version(lldev->hu.hdev);
> +   if (version < 0)
> +   return version;
> +
> +   chip = (version & 0x7C00) >> 10;
> +   min_ver = (version & 0x007F);
> +   maj_ver = (version & 0x0380) >> 7;
> +   if (version & 0x8000)
> +   maj_ver |= 0x0008;
> +
> +   snprintf(bts_scr_name, sizeof(bts_scr_name),
> +"ti-connectivity/TIInit_%d.%d.%d.bts",
> +