Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early

[George Cherian <george.cherian@ti.com>]

On 5/8/2014 10:30 PM, Ezequiel García wrote:
> Hi George,
>
> On 29 April 2014 04:58, George Cherian <george.cherian@ti.com> wrote:
>> On 4/29/2014 11:49 AM, Yegor Yefremov wrote:
>>> On Thu, Apr 24, 2014 at 11:11 PM, Ezequiel Garcia
>>> <ezequiel@vanguardiasur.com.ar> wrote:
>>>> The DMA controller is needed for the USB controller to be correctly
>>>> registered. Therefore, if the DMA node is located at the end an
>>>> unecessary
>>>> probe deferral is produced systematically.
>>>>
>>>> This is easily fixed by moving the node at the beggining of the child
>>>> list,
>>>> so it's probed first.
>> This will give issues on module removal.
>> Since we use device_for_each_child in remove patch, it will try to remove
>> cppi dma controller, while the channel
>> is still in use by musb node.
>>
> OK, this seems confusing: are you sure module removal works?
No it does not .
>
> Doing this simple test on v3.15-rcN:
>
> $ modprobe musb_dsps
> $ modprobe musb_am335x
> $ modprobe musb_am335x -r
>
> And the kernel blows up :-(
>
> I've been debugging this and I think we simply cannot support removal
> of the musb_am335x
> module.
>
> Had this ever worked before
Nope. I feel the whole problem is because how its modeled in dt.

If you look at the TRM following are the memory maps for the USB modules
USB control Module 0x44e10_0620

USBSS             0x4740_0000

USB0               0x4740_1000
USB0_PHY      0x4740_1300
USB0_CORE    0x4740_1400

USB1               0x4740_1800
USB1_PHY      0x4740_1b00
USB1_CORE    0x4740_1c00

CPPI DMA Controller 0x4740_2000
CPPI DMA Scheduler 0x4740_3000
Queue Manager         0x4740_4000

Now in the curent DT we have  the follwoing
USBSS {
     usb_ctrl_mod: {
         0x44e10_0620
     }
     usb0_phy:{
     0x4740_1300
     }
     usb0: {
     0x4740_1000
     0x4740_1400
     }
     usb1_phy: {
     0x4740_1b00
     }
     usb1:{
     0x4740_1800
     0x4740_1c00
     }
     cppi41dma: {
     0x4740_2000
     0x4740_3000
     0x4740_4000
     }
}

Just by remodelling the dt the whole problem can be solved.
I am still not convinced why we should not be doing it?
Because neither ways its not the exact representation of the H/W.

I will send a patch as RFC for the same.


-- 
-George

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html