From: george.cherian@ti•com (George Cherian)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
Date: Fri, 9 May 2014 11:52:59 +0530 [thread overview]
Message-ID: <536C7443.4000805@ti.com> (raw)
In-Reply-To: <CAAEAJfCG3c++WBgeipF6sCE1-9pHgU80t2Mpz0Y4koU5-uEwSA@mail.gmail.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
next prev parent reply other threads:[~2014-05-09 6:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-24 21:11 [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early Ezequiel Garcia
2014-04-29 6:19 ` Yegor Yefremov
2014-04-29 7:58 ` George Cherian
2014-04-29 8:06 ` Sebastian Andrzej Siewior
2014-04-29 8:27 ` George Cherian
2014-04-29 9:09 ` Sebastian Andrzej Siewior
2014-04-29 13:50 ` Ezequiel García
2014-05-08 17:00 ` Ezequiel García
2014-05-09 6:22 ` George Cherian [this message]
2014-05-09 7:25 ` Sebastian Andrzej Siewior
2014-05-09 10:07 ` George Cherian
2014-05-09 13:26 ` Ezequiel García
2014-05-12 4:59 ` George Cherian
2014-05-12 14:02 ` Ezequiel Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=536C7443.4000805@ti.com \
--to=george.cherian@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox