As a followup to my earlier patch posted to koen’s kernel repository, these are changes for the meta-ti layer used when building with bitbake. I’m not sure what the best way is to submit these, but I put them here at least initially.
The first patch changes the defconfig to enable UIO and UIO_PRUSS as modules. However, the existing code isn’t properly initializing the PRUSS. The second patch releases the PRUSS from reset when enabling, which happens when inserting uio_pruss module. The code changes for this second patch are identical to what I submitted to koen, except it is done by adding a .patch file and modifying the .bb recipe to use that patch, since the actual kernel code is not in the meta-ti repository.
We attached a method to clock opts so that when the pruss fclk is shut
down, it SHOULD place the PRUSS back into reset. It doesn't seem to
work, which makes me think that when we rmmod uio_pruss, and it frees
the pruss clock (which the module does), that something is either not
getting refcounted down, or disabling the clock "pruss" (which is
really an alias for the PRU UART clock in the current kernel) it
doesn't follow through with shutting down all the clocks the rest of
the way up the tree.
If somebody could explain why this would be very helpful. This clock
tree / power domain linkage is still a bit of a mystery to me.
I've decided to mostly ignore this for now. The only negative side
effect that I can think of is that if you modprobe uio_pruss then
change your mind and rmmod it the fclk and ocp clocks (to L3 and L4)
will be running, perhaps resulting in SLIGHTLY more power consumption.
OK, the readme says to submit the pull requests to an e-mail. I'm new
to git, the only place I've seen "pull requests" used with that term
is on github, which only applies to github repositories forked from
other github repositories. OK, so I'll assume it means send an e-mail
and say "pull from this remote public repo". So then what does that
mean? Let's say I would use github. All of their docs for forking are
based on other github repos. So if I want to publish my commits,
wouldn't that mean I need to start a github repo, clone it, set up
meta-ti as remote, merge all meta-ti into my empty master, then make
my commits, and then push everything? That doesn't make sense now as
I'm copying the entire repository to github? Is that really how it's
supposed to work? Github has lots of awesome docs but they all assume
a closed github-only world...
As a followup to my earlier patch posted to koen's kernel repository,
these are changes for the meta-ti layer used when building with bitbake.
I'm not sure what the best way is to submit these, but I put them here
at least initially.
The first patch changes the defconfig to enable UIO and UIO_PRUSS as
modules.
This I can not pull in my upstream repo,
- I do not have pruss driver queued for upstream
- since it is meant for bitbake and not for upstream.
However, the existing code isn't properly initializing the
PRUSS. The second patch releases the PRUSS from reset when enabling,
which happens when inserting uio_pruss module. The code changes for this
second patch are identical to what I submitted to koen, except it is
done by adding a .patch file and modifying the .bb recipe to use that
patch, since the actual kernel code is not in the meta-ti repository.
This code is not required anymore; I have cleaned up the code and for
achieving reset we are using very standard interface provided by hwmod
callback api's.
Strictly from upstream perspective.
Refer to the file "arch/arm/mach-omap2/omap_hwmod_33xx_data.c"
We attached a method to clock opts so that when the pruss fclk is shut
down, it SHOULD place the PRUSS back into reset. It doesn't seem to
work, which makes me think that when we rmmod uio_pruss, and it frees
the pruss clock (which the module does), that something is either not
getting refcounted down, or disabling the clock "pruss" (which is
really an alias for the PRU UART clock in the current kernel) it
doesn't follow through with shutting down all the clocks the rest of
the way up the tree.
Please read my comments on your patch posting, we don't need this api's
In clock_ops.
If somebody could explain why this would be very helpful. This clock
tree / power domain linkage is still a bit of a mystery to me.
I've decided to mostly ignore this for now. The only negative side
effect that I can think of is that if you modprobe uio_pruss then
change your mind and rmmod it the fclk and ocp clocks (to L3 and L4)
will be running, perhaps resulting in SLIGHTLY more power consumption.
I have tested clock_enable/disable and I believe it does work properly.
Let me test it again here...
NOTE: I have not tested insmod/rmmod, since I always use built into kernel.
Thanks,
Vaibhav
I have tested clock_enable/disable and I believe it does work properly.
Let me test it again here...
NOTE: I have not tested insmod/rmmod, since I always use built into kernel.
That's a fairly important use case, though, so that you can set the
module parameter to adjust the size of the DDR buffer you wish to
allocate. Also, the last uio_pruss driver I saw only called clk_put()
as a result of module removal, so I don't see how you'd be able to
test that if it were statically compiled into the kernel... unless
there was some other change to uio_pruss.ko that did the clk_put()
elsewhere (I kind of hope not, I don't think the PRUSS should
automatically stop on release -- doing it in platform_driver.remove is
definitely the right place).
When we get the updated kernel here I will test it as a module and
make sure it's OK.
This code is not required anymore; I have cleaned up the code and for achieving reset we are using very standard interface provided by hwmod callback api's.
I'll check into this - last time we pulled from anything other than
angstrom we didn't see this, which either means that I missed it (very
possible) or this change is fairly recent.
No, it is meant for the meta-ti layer, not bitbake. For bitbake the git repo would have been git://git.openembedded.org/bitbake
and furthermore, that has no concept of kernels whatsoever.
> I have tested clock_enable/disable and I believe it does work properly.
> Let me test it again here...
>
> NOTE: I have not tested insmod/rmmod, since I always use built into kernel.
That's a fairly important use case, though, so that you can set the
module parameter to adjust the size of the DDR buffer you wish to
allocate. Also, the last uio_pruss driver I saw only called clk_put()
as a result of module removal, so I don't see how you'd be able to
test that if it were statically compiled into the kernel...
I should have been more clear here, sorry for confusion.
When I meant testing, I was referring to clock-tree from clock enable and disable perspective. As of now I do not test module functionality, since my
Only current target is to get baseport in the mainline.
unless
there was some other change to uio_pruss.ko that did the clk_put()
elsewhere (I kind of hope not, I don't think the PRUSS should
automatically stop on release -- doing it in platform_driver.remove is
definitely the right place).
When we get the updated kernel here I will test it as a module and
make sure it's OK.
>This code is not required anymore; I have cleaned up the code and for achieving reset we are using very standard interface provided by hwmod callback api's.
I'll check into this - last time we pulled from anything other than
angstrom we didn't see this, which either means that I missed it (very
possible) or this change is fairly recent.
It is not that recent, but it is possible that it is not merged in any of
These meta-ti or bitbake thing. I am not sure though.
Have you succeeded in compiling your own binary firmware using pasm and validated that it runs? Last I heard nobody could confirm that the pasm for PRUSSv1 works on the PRUSSv2 in the Beaglebone.
On 27-2-2012 22:21, wrote: FYI, I’ve been running several different binaries generated with one of the old pasm’s (version 0.76) for a while now. My guess is that the new PRUSS has an extended instruction set but is otherwise compatible with the old one. — Bas
