Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1429000 > unrolled thread

Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform  declaration. David Lechner <david@lechnology.com> - 2016-06-22 19:10 +0200
    Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform  declaration. Sekhar Nori <nsekhar@ti.com> - 2016-06-24 08:20 +0200
      Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform  declaration. David Lechner <david@lechnology.com> - 2016-06-24 18:10 +0200

#1429000 — Re: [PATCH v5 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.

On 05/25/2016 06:15 AM, Sekhar Nori wrote:
> On Tuesday 10 May 2016 10:14 PM, David Lechner wrote:
>> On 05/10/2016 06:26 AM, Sergei Shtylyov wrote:
>>> On 5/10/2016 2:46 AM, David Lechner wrote:
>>>
>>>> The CFGCHIP registers are used by a number of devices, so using a syscon
>>>> device to share them. The first consumer of this will by the
>>>> phy-da8xx-usb
>>>> driver.
>>>>
>>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> [...]
>>>> diff --git a/arch/arm/mach-davinci/devices-da8xx.c
>>>> b/arch/arm/mach-davinci/devices-da8xx.c
>>>> index 725e693..69d11a1 100644
>>>> --- a/arch/arm/mach-davinci/devices-da8xx.c
>>>> +++ b/arch/arm/mach-davinci/devices-da8xx.c
>>>> @@ -11,6 +11,7 @@
>>>>    * (at your option) any later version.
>>>>    */
>>>>   #include <linux/init.h>
>>>> +#include <linux/platform_data/syscon.h>
>>>>   #include <linux/platform_device.h>
>>>>   #include <linux/dma-contiguous.h>
>>>>   #include <linux/serial_8250.h>
>>>> @@ -1109,3 +1110,30 @@ int __init da850_register_sata(unsigned long
>>>> refclkpn)
>>>>       return platform_device_register(&da850_sata_device);
>>>>   }
>>>>   #endif
>>>> +
>>>> +static struct syscon_platform_data da8xx_cfgchip_platform_data = {
>>>> +    .label    = "cfgchip",
>>>> +};
>>>> +
>>>> +static struct resource da8xx_cfgchip_resources[] = {
>>>> +    {
>>>> +        .start    = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP0_REG,
>>>> +        .end    = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP4_REG + 3,
>>>> +        .flags    = IORESOURCE_MEM,
>>>> +    },
>>>> +};
>>>> +
>>>> +static struct platform_device da8xx_cfgchip_device = {
>>>> +    .name    = "syscon",
>>>> +    .id    = 0,
>>>
>>>      Again, -1.
>>>
>>> [...]
>>>
>>> MBR, Sergei
>>>
>>
>> I wish you would have noticed this when I first submitted it. I remember
>> going back and forth about this. But it has been too long and I can't
>> remember the reason why I chose to go this way.
>>
>> It seems like changing it broke something with either this one or the
>> phy device and I opted to keep it this way on both to be consistent. For
>> example, the USB devices both use id = 0 as well even though there are
>> only one of each type.
>
> Agree with Sergei here. Can you confirm what broke exactly? I think the
> USB needs to be fixed too.
>
> Thanks,
> Sekhar
>

I have made the changes from id = 0 to id = -1. I'm not sure what broke 
before, but it is working now.

Re: USB needing fixed, I'm not sure how to do this and I won't have time 
for at least the next 2 or 3 months to do anything about it. The problem 
is that the MUSB can't detect the ID pin. As a workaround, it is
detecting the VBUS state and using that to determine the ID pin state. 
So, when you attach a self-powered device, it tells the VBUS to turn 
off, which in turn triggers the workaround to say that the ID pin has 
changed state.

If anyone has any ideas on what to do about this, I will be glad to have 
a look at it. It will just have to wait a bit though.

[toc] | [next] | [standalone]

#1430388

On Wednesday 22 June 2016 10:37 PM, David Lechner wrote:
> On 05/25/2016 06:15 AM, Sekhar Nori wrote:
>> On Tuesday 10 May 2016 10:14 PM, David Lechner wrote:
>>> On 05/10/2016 06:26 AM, Sergei Shtylyov wrote:
>>>> On 5/10/2016 2:46 AM, David Lechner wrote:

[...]

>>>>> +static struct platform_device da8xx_cfgchip_device = {
>>>>> +    .name    = "syscon",
>>>>> +    .id    = 0,
>>>>
>>>>      Again, -1.
>>>>
>>>> [...]
>>>>
>>>> MBR, Sergei
>>>>
>>>
>>> I wish you would have noticed this when I first submitted it. I remember
>>> going back and forth about this. But it has been too long and I can't
>>> remember the reason why I chose to go this way.
>>>
>>> It seems like changing it broke something with either this one or the
>>> phy device and I opted to keep it this way on both to be consistent. For
>>> example, the USB devices both use id = 0 as well even though there are
>>> only one of each type.
>>
>> Agree with Sergei here. Can you confirm what broke exactly? I think the
>> USB needs to be fixed too.
>>
>> Thanks,
>> Sekhar
>>
> 
> I have made the changes from id = 0 to id = -1. I'm not sure what broke
> before, but it is working now.

Thanks!

> 
> Re: USB needing fixed, I'm not sure how to do this and I won't have time
> for at least the next 2 or 3 months to do anything about it. The problem
> is that the MUSB can't detect the ID pin. As a workaround, it is
> detecting the VBUS state and using that to determine the ID pin state.
> So, when you attach a self-powered device, it tells the VBUS to turn
> off, which in turn triggers the workaround to say that the ID pin has
> changed state.

I seem to be missing the original problem report. Can you provide a link
to the discussion?

Thanks,
Sekhar

[toc] | [prev] | [next] | [standalone]

#1430789

>>
>> Re: USB needing fixed, I'm not sure how to do this and I won't have time
>> for at least the next 2 or 3 months to do anything about it. The problem
>> is that the MUSB can't detect the ID pin. As a workaround, it is
>> detecting the VBUS state and using that to determine the ID pin state.
>> So, when you attach a self-powered device, it tells the VBUS to turn
>> off, which in turn triggers the workaround to say that the ID pin has
>> changed state.
>
> I seem to be missing the original problem report. Can you provide a link
> to the discussion?
>
> Thanks,
> Sekhar
>

Here is the thread: https://lkml.org/lkml/2016/5/9/942

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web