Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

Hi all,

> Am 17.07.2019 um 12:51 schrieb Merlijn Wajer <merlijn@wizzup.org>:
> 
> Hi,
> 
> On 10/03/2019 08:07, H. Nikolaus Schaller wrote:
>> 
>>> Am 10.03.2019 um 00:14 schrieb Merlijn Wajer <merlijn@wizzup.org>:
>>> 
>>> Hi,
>>> 
>>> On 15/02/2019 14:09, H. Nikolaus Schaller wrote:
>>> 
>>>>>> At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works
>>>>>> with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
>>>>> 
>>>>> Maybe you can compare with what we have here:
>>>>> https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pvr
>>>> 
>>>> I'll take a look into it especially how omaplfb is done.
>>>> 
>>>> First observation is that there is a "flat" tree while I am working on a structured one...
>>>> But that is just a marginal difference (mainly significant for Makefile writers).
>>> 
>>> I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work:
>>> https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y
>>> 
>>> Should I add this as maemo-leste-n900-5.0 branch (or something) to
>>> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ?
>> 
>> Yes, that would be nice to be able to easily compare stuff.
> 
> I've just pushed the Maemo Leste v5.1 branch + patches here:
> 
> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/n900/v5.1-patch
> 
> This works on N900 with X, but it doesn't use DRM yet. I'm wondering
> what a next logical step would be: to try and modules to load/probe on
> another device (I have a droid4 or a Pandaboard ES rev B1), or to try
> and get DRM PowerVR to work on the N900, with omapdrmfb and dri3wsegl.
> 
> For either path, I'll probably need some help. Any updates from anyone
> else? Maybe we should list things people can work - perhaps document
> progress in github issues. (Mailing list is also fine, BTW)
> 
> Cheers,
> Merlijn
> 

I also have pushed good news to

	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr

Thanks to the help from the Pyra community, I was able to get a (binary) reference
implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.

With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.

I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree)
on the Pyra.

In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?

* includes internal API fixes for kernels up to v5.3
* lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
* has Kconfig and Makefiles for in-kernel configuration (no separate build system)
* builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
  pvrsrvkm
  e.g. pvrsrvkm_omap_omap5_sgx544_116
* the correct kernel module is automatically probed by matching .compatible in device tree
  so that the code is multi-platform friendly
* includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
* code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
* has got a ToDo to describe what should be done during staging phase

	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO

My plans for the next steps are:

* do more testing (e.g. X11, kmscube)
* check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
* try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
  missing the user-space libraries for MIPS).

BR,
Nikolaus

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [190814 08:57]:
> I also have pushed good news to
> 
> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
> 
> Thanks to the help from the Pyra community, I was able to get a (binary) reference
> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
> 
> With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
> 
> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree)
> on the Pyra.
> 
> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
> 
> * includes internal API fixes for kernels up to v5.3
> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
> * has Kconfig and Makefiles for in-kernel configuration (no separate build system)
> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
>   pvrsrvkm
>   e.g. pvrsrvkm_omap_omap5_sgx544_116
> * the correct kernel module is automatically probed by matching .compatible in device tree
>   so that the code is multi-platform friendly
> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
> * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
> * has got a ToDo to describe what should be done during staging phase
> 
> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO
> 
> My plans for the next steps are:
> 
> * do more testing (e.g. X11, kmscube)
> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
>   missing the user-space libraries for MIPS).

That sounds good to me, just one comment. Before getting these into
staging, I'd like to have omap variants use proper interconnect
target module in devicetree like we already have in omap4.dtsi
as target-module@56000000. This should simplify things further
as the module child device driver(s) can just enable things with
runtime PM and we can leave out all the legacy hwmod platform data
that sounds like you're still carrying.

I have patches here to add similar interconnect target modules for
at least omap34xx, omap36xx, omap5, and am335x that I'll try to post
later on today to play with. For am335x, things still depend on the
recentely posted prm rstctrl patches. I'm not sure if I already
did a dts patch for dra7 yet, need to check.

Regards,

Tony

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 14.08.2019 um 11:47 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [190814 08:57]:
>> I also have pushed good news to
>> 
>> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
>> 
>> Thanks to the help from the Pyra community, I was able to get a (binary) reference
>> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
>> 
>> With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
>> 
>> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree)
>> on the Pyra.
>> 
>> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
>> 
>> * includes internal API fixes for kernels up to v5.3
>> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
>> * has Kconfig and Makefiles for in-kernel configuration (no separate build system)
>> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
>>  pvrsrvkm
>>  e.g. pvrsrvkm_omap_omap5_sgx544_116
>> * the correct kernel module is automatically probed by matching .compatible in device tree
>>  so that the code is multi-platform friendly
>> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
>> * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
>> * has got a ToDo to describe what should be done during staging phase
>> 
>> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO
>> 
>> My plans for the next steps are:
>> 
>> * do more testing (e.g. X11, kmscube)
>> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
>> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
>>  missing the user-space libraries for MIPS).
> 
> That sounds good to me, just one comment. Before getting these into
> staging, I'd like to have omap variants use proper interconnect
> target module in devicetree like we already have in omap4.dtsi
> as target-module@56000000. This should simplify things further
> as the module child device driver(s) can just enable things with
> runtime PM and we can leave out all the legacy hwmod platform data
> that sounds like you're still carrying.

Yes, there is still a lot of SoC-glue included:

	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue

It would indeed be a good move to simplify and reduce the glue code
and make it more maintainable / stable / identical on different platforms.

> 
> I have patches here to add similar interconnect target modules for
> at least omap34xx, omap36xx, omap5, and am335x that I'll try to post
> later on today to play with. For am335x, things still depend on the
> recentely posted prm rstctrl patches. I'm not sure if I already
> did a dts patch for dra7 yet, need to check.

I assume it is not yet in linux-next... So something for v5.5 or later.

BR and thanks,
Nikolaus

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [190814 10:34]:
> 
> > Am 14.08.2019 um 11:47 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [190814 08:57]:
> >> I also have pushed good news to
> >> 
> >> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
> >> 
> >> Thanks to the help from the Pyra community, I was able to get a (binary) reference
> >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
> >> 
> >> With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
> >> 
> >> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree)
> >> on the Pyra.
> >> 
> >> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
> >> 
> >> * includes internal API fixes for kernels up to v5.3
> >> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
> >> * has Kconfig and Makefiles for in-kernel configuration (no separate build system)
> >> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
> >>  pvrsrvkm
> >>  e.g. pvrsrvkm_omap_omap5_sgx544_116
> >> * the correct kernel module is automatically probed by matching .compatible in device tree
> >>  so that the code is multi-platform friendly
> >> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
> >> * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
> >> * has got a ToDo to describe what should be done during staging phase
> >> 
> >> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO
> >> 
> >> My plans for the next steps are:
> >> 
> >> * do more testing (e.g. X11, kmscube)
> >> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
> >> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
> >>  missing the user-space libraries for MIPS).
> > 
> > That sounds good to me, just one comment. Before getting these into
> > staging, I'd like to have omap variants use proper interconnect
> > target module in devicetree like we already have in omap4.dtsi
> > as target-module@56000000. This should simplify things further
> > as the module child device driver(s) can just enable things with
> > runtime PM and we can leave out all the legacy hwmod platform data
> > that sounds like you're still carrying.
> 
> Yes, there is still a lot of SoC-glue included:
> 
> 	https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue
> 
> It would indeed be a good move to simplify and reduce the glue code
> and make it more maintainable / stable / identical on different platforms.

OK yeah all that should just disappear :)

> > I have patches here to add similar interconnect target modules for
> > at least omap34xx, omap36xx, omap5, and am335x that I'll try to post
> > later on today to play with. For am335x, things still depend on the
> > recentely posted prm rstctrl patches. I'm not sure if I already
> > did a dts patch for dra7 yet, need to check.
> 
> I assume it is not yet in linux-next... So something for v5.5 or later.

Well I just posted some sgx interconnect target module patches. We might
still have them in v5.4 assuming people manage to review and test them.

Regards,

Tony

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Adam Ford]

On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * H. Nikolaus Schaller <hns@goldelico.com> [190814 10:34]:
> >
> > > Am 14.08.2019 um 11:47 schrieb Tony Lindgren <tony@atomide.com>:
> > >
> > > * H. Nikolaus Schaller <hns@goldelico.com> [190814 08:57]:
> > >> I also have pushed good news to
> > >>
> > >>    https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
> > >>
> > >> Thanks to the help from the Pyra community, I was able to get a (binary) reference
> > >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
> > >>
> > >> With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
> > >>
> > >> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree)
> > >> on the Pyra.
> > >>
> > >> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
> > >>
> > >> * includes internal API fixes for kernels up to v5.3
> > >> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
> > >> * has Kconfig and Makefiles for in-kernel configuration (no separate build system)
> > >> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
> > >>  pvrsrvkm
> > >>  e.g. pvrsrvkm_omap_omap5_sgx544_116
> > >> * the correct kernel module is automatically probed by matching .compatible in device tree
> > >>  so that the code is multi-platform friendly
> > >> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
> > >> * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
> > >> * has got a ToDo to describe what should be done during staging phase
> > >>
> > >>    https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO
> > >>
> > >> My plans for the next steps are:
> > >>
> > >> * do more testing (e.g. X11, kmscube)
> > >> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
> > >> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
> > >>  missing the user-space libraries for MIPS).



> > >
> > > That sounds good to me, just one comment. Before getting these into
> > > staging, I'd like to have omap variants use proper interconnect
> > > target module in devicetree like we already have in omap4.dtsi
> > > as target-module@56000000. This should simplify things further
> > > as the module child device driver(s) can just enable things with
> > > runtime PM and we can leave out all the legacy hwmod platform data
> > > that sounds like you're still carrying.
> >
> > Yes, there is still a lot of SoC-glue included:
> >
> >       https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue
> >
> > It would indeed be a good move to simplify and reduce the glue code
> > and make it more maintainable / stable / identical on different platforms.
>
> OK yeah all that should just disappear :)
>
> > > I have patches here to add similar interconnect target modules for
> > > at least omap34xx, omap36xx, omap5, and am335x that I'll try to post
> > > later on today to play with. For am335x, things still depend on the
> > > recentely posted prm rstctrl patches. I'm not sure if I already
> > > did a dts patch for dra7 yet, need to check.
> >
> > I assume it is not yet in linux-next... So something for v5.5 or later.
>
> Well I just posted some sgx interconnect target module patches. We might
> still have them in v5.4 assuming people manage to review and test them.

Nikolaus,

I tested Tony's change and I can confirm that I can read the value
when enabled.  Should I apply his patches to your branch before I
test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a
DM3730.  I am not sure if the AM3517 is even on the radar, but it has
an sgx530 as well.

adam

>
> Regards,
>
> Tony

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tony Lindgren]

* Adam Ford <aford173@gmail.com> [190816 23:02]:
> On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren <tony@atomide.com> wrote:
> > Well I just posted some sgx interconnect target module patches. We might
> > still have them in v5.4 assuming people manage to review and test them.
> 
> Nikolaus,
> 
> I tested Tony's change and I can confirm that I can read the value
> when enabled.  Should I apply his patches to your branch before I
> test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a
> DM3730.  I am not sure if the AM3517 is even on the radar, but it has
> an sgx530 as well.

My estimate is am3517 is wired the same way as omap34xx with a 60%
chance, then 30% chance it's wired the same way as omap36xx, and then
10% chance for similar wiring to am335x.. So hopefully that leaves 0%
chance for yet something different for it's wiring :)

If you have a chance please give it a try. Also check the TRM for the
sgx sysconfig register bits to see which of the above matches, and if
3517 has a related rstctrl register like am335x has.

Regards,

Tony

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

Hi Adam,

> Am 17.08.2019 um 01:01 schrieb Adam Ford <aford173@gmail.com>:
> 
> 
> Nikolaus,
> 
> I tested Tony's change and I can confirm that I can read the value
> when enabled.  Should I apply his patches to your branch before I
> test, or is it go too to go as-is?

My branch is currently as-is and not aware of Tony's patches and based on v5.3-rc3.
I think I will have to remove some glue code which tries to do the platform
reset and enables clocks and replace by pm_runtime_get_sync() before it fits
together. Then we can likely remove the omap-pvr-soc-glue branch at least
partially and/or replace by Tony's patches before they arrive in mainline.

The current status of my branch is that it works on OMAP5/Pyra but a
quick test on BeagleBone or GTA04 did show some reset/clock errors and
it did not more than creating /proc/pvr. pvrsrvctl --start did fail.

Which means that the omap-pvr-soc-glue patches are currently broken
with 5.3-rc3 anyways...

I'll look at it as soon as possible.

> I've got an AM3517, OMAP35 and a
> DM3730.  I am not sure if the AM3517 is even on the radar, but it has
> an sgx530 as well.

Good to know and keep in mind.

BR,
Nikolaus

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Adam Ford]

On Sat, Aug 17, 2019 at 2:03 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * Adam Ford <aford173@gmail.com> [190816 23:02]:
> > On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren <tony@atomide.com> wrote:
> > > Well I just posted some sgx interconnect target module patches. We might
> > > still have them in v5.4 assuming people manage to review and test them.
> >
> > Nikolaus,
> >
> > I tested Tony's change and I can confirm that I can read the value
> > when enabled.  Should I apply his patches to your branch before I
> > test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a
> > DM3730.  I am not sure if the AM3517 is even on the radar, but it has
> > an sgx530 as well.
>
> My estimate is am3517 is wired the same way as omap34xx with a 60%
> chance, then 30% chance it's wired the same way as omap36xx, and then
> 10% chance for similar wiring to am335x.. So hopefully that leaves 0%
> chance for yet something different for it's wiring :)

Based on [1], I went under the assumption it was wired like the
omap34xx.  I applied your omap34 patches to the am3517.dtsi, and I was
able to get the same response as I did for the omap3530.  Do you want
me to post the patches to the mailing list, or do you want to do it?

adam

[1] - http://processors.wiki.ti.com/index.php/GSG:_AM35x_and_OMAP35x_Rebuilding_the_Software#How_to_check_for_SGX_core_revision

>
> If you have a chance please give it a try. Also check the TRM for the
> sgx sysconfig register bits to see which of the above matches, and if
> 3517 has a related rstctrl register like am335x has.
>
> Regards,
>
> Tony

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Adam Ford]

On Wed, Aug 14, 2019 at 3:56 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi all,
>
> > Am 17.07.2019 um 12:51 schrieb Merlijn Wajer <merlijn@wizzup.org>:
> >
> > Hi,
> >
> > On 10/03/2019 08:07, H. Nikolaus Schaller wrote:
> >>
> >>> Am 10.03.2019 um 00:14 schrieb Merlijn Wajer <merlijn@wizzup.org>:
> >>>
> >>> Hi,
> >>>
> >>> On 15/02/2019 14:09, H. Nikolaus Schaller wrote:
> >>>
> >>>>>> At least I can download and start firmware. I just have to find a way to fix the omaplfb so that it works
> >>>>>> with our omapdrm based panels to runs the CLipBlit test [1] on modern kernels...
> >>>>>
> >>>>> Maybe you can compare with what we have here:
> >>>>> https://github.com/maemo-leste/n9xx-linux/tree/pvr-wip-4.15.7/drivers/gpu/pvr
> >>>>
> >>>> I'll take a look into it especially how omaplfb is done.
> >>>>
> >>>> First observation is that there is a "flat" tree while I am working on a structured one...
> >>>> But that is just a marginal difference (mainly significant for Makefile writers).
> >>>
> >>> I've ported the Maemo Leste kernel + pvr to 5.0 and it seems to work:
> >>> https://github.com/maemo-leste/n9xx-linux/commits/pvr-wip-5.0.y
> >>>
> >>> Should I add this as maemo-leste-n900-5.0 branch (or something) to
> >>> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx ?
> >>
> >> Yes, that would be nice to be able to easily compare stuff.
> >
> > I've just pushed the Maemo Leste v5.1 branch + patches here:
> >
> >       https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/n900/v5.1-patch
> >
> > This works on N900 with X, but it doesn't use DRM yet. I'm wondering
> > what a next logical step would be: to try and modules to load/probe on
> > another device (I have a droid4 or a Pandaboard ES rev B1), or to try
> > and get DRM PowerVR to work on the N900, with omapdrmfb and dri3wsegl.
> >
> > For either path, I'll probably need some help. Any updates from anyone
> > else? Maybe we should list things people can work - perhaps document
> > progress in github issues. (Mailing list is also fine, BTW)
> >
> > Cheers,
> > Merlijn
> >
>
> I also have pushed good news to
>
>         https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr
>
> Thanks to the help from the Pyra community, I was able to get a (binary) reference
> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.

just a question,

If DRM is working, does that mean it works without needing the overhead of X?

adam
>
> With that reference setup I was able to fix my Makefiles for the staging/pvr implementation.
>
> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the LetuxOS kernel tree)
> on the Pyra.
>
> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14?
>
> * includes internal API fixes for kernels up to v5.3
> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for inclusion in linux-next
> * has Kconfig and Makefiles for in-kernel configuration (no separate build system)
> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, omap5, dra7 etc.
>   pvrsrvkm
>   e.g. pvrsrvkm_omap_omap5_sgx544_116
> * the correct kernel module is automatically probed by matching .compatible in device tree
>   so that the code is multi-platform friendly
> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings documentation
> * code base should also support JZ4780/CI20 and some Intel Atom processors (CedarView, Poulsbo)
> * has got a ToDo to describe what should be done during staging phase
>
>         https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO
>
> My plans for the next steps are:
>
> * do more testing (e.g. X11, kmscube)
> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, OpenPandora)
> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline kernels and I am
>   missing the user-space libraries for MIPS).
>
> BR,
> Nikolaus
>

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 19.08.2019 um 21:43 schrieb Adam Ford <aford173@gmail.com>:
> 
>> Thanks to the help from the Pyra community, I was able to get a (binary) reference
>> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
> 
> just a question,
> 
> If DRM is working, does that mean it works without needing the overhead of X?

Yes, we have to kill X11 to successfully run the gles1test1. An interesting question
will be how to mix both... E.g. have a 3D rendering in a window controlled by some
window manager.

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Merlijn Wajer]

[-- Attachment #1.1: Type: text/plain, Size: 741 bytes --]

Hi,

On 20/08/2019 08:48, H. Nikolaus Schaller wrote:
> 
>> Am 19.08.2019 um 21:43 schrieb Adam Ford <aford173@gmail.com>:
>>
>>> Thanks to the help from the Pyra community, I was able to get a (binary) reference
>>> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1.
>>
>> just a question,
>>
>> If DRM is working, does that mean it works without needing the overhead of X?
> 
> Yes, we have to kill X11 to successfully run the gles1test1. An interesting question
> will be how to mix both... E.g. have a 3D rendering in a window controlled by some
> window manager.
> 

This is probably what you want to look at / start with:
https://github.com/TexasInstruments/dri3wsegl

Cheers,
Merlijn


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tony Lindgren]

* Adam Ford <aford173@gmail.com> [190819 19:26]:
> On Sat, Aug 17, 2019 at 2:03 AM Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Adam Ford <aford173@gmail.com> [190816 23:02]:
> > > On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren <tony@atomide.com> wrote:
> > > > Well I just posted some sgx interconnect target module patches. We might
> > > > still have them in v5.4 assuming people manage to review and test them.
> > >
> > > Nikolaus,
> > >
> > > I tested Tony's change and I can confirm that I can read the value
> > > when enabled.  Should I apply his patches to your branch before I
> > > test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a
> > > DM3730.  I am not sure if the AM3517 is even on the radar, but it has
> > > an sgx530 as well.
> >
> > My estimate is am3517 is wired the same way as omap34xx with a 60%
> > chance, then 30% chance it's wired the same way as omap36xx, and then
> > 10% chance for similar wiring to am335x.. So hopefully that leaves 0%
> > chance for yet something different for it's wiring :)
> 
> Based on [1], I went under the assumption it was wired like the
> omap34xx.  I applied your omap34 patches to the am3517.dtsi, and I was
> able to get the same response as I did for the omap3530.  Do you want
> me to post the patches to the mailing list, or do you want to do it?

OK great, yeah please post patches :)

Thanks,

TOny

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tony Lindgren]

Hi,

* H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
> Hi all,
> with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived
> upstream, so we do no longer need them here.
> 
> Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some
> more issues:
> * omap4 build only needs to distinguish between omap4420/30/60 and omap4470,
>   because the latter has an sgx544 inside and the other sgx540
>   This is solved by creating a new omap4470.dts
> * I have added proper reg values and interrupts to the omap4 device
>   tree node of the sgx (child node of the target-module)
> * some updates to my sgxdump and sgxdemo scripts (assuming simple
>   Debian Stretch rootfs)
> * James Hilliard has contributed a fix for osfunc.c
> * omap2plus also needs to be configured for STAGING and PREEMPT
>   to be able to compile the driver
> * I have added the __always_inline fix [2] which is needed for v5.4 with
>   CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds)
> 
> Unfortunately Tero's rstctrl patches did not yet make it upstream (or even
> linux-next) so I also have a copy in this branch.
> 
> Results of first testing are:
> * OMAP3530 (OpenPandora, BeagleBoard C): fails with
> [  559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed
> 
> * DM3730 (GTA04, BeagleBoard XM): kernel module loads
> 
> * OMAP4460 (Pandaboard ES): kernel module loads
> 
> * AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
> [  204.246706] omap_reset_deassert: timedout waiting for gfx:0

Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
5.4-rc1-ipc from few days ago, the earlier versions had still issues.

> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
> [  304.140363] clock-controller:clk:0000:0: failed to enable
> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)

Hmm no idea what might be up with this one. Did some clkctrl clock
fixes maybe cause a regression here? Tero do you have any ideas?

> * OMAP5 with omap2plus_defconfig:
> root@letux:~# echo on > $(find /sys -name control | grep \/5600)
> [  213.490926] clock-controller:clk:0000:0: failed to enable
> root@letux:~# 
> 
> * pvrsrvctl --start --no-module:
>   reports (where the kernel module loads) that the uKernel does not run
> 
> So I have several ideas what the reasons for the problems on the non-omap5
> devices could be:
> * initial code may have some omap5 specific hack inside
> * or has omap5 specific magic constants
> * uKernel may "know" on which platform it runs and
>   we would need differently patched user-space code
>   for each one
> * omap5 has a dual core sgx544 while the other
>   have single core
> * the register address translation is not yet correct and
>   this inhibits communicating of the user-space libs
>   with the uKernel
> 
> Maybe, if someone can point me to a complete and working BeagleBone source
> tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare
> code and address setup to find what makes the difference.

Regards,

Tony

> [1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr
> [2]: https://lkml.org/lkml/2019/10/2/201

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 07.10.2019 um 17:52 schrieb Tony Lindgren <tony@atomide.com>:
> 
> Hi,
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
>> 
>> 
>> * AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
>> [  204.246706] omap_reset_deassert: timedout waiting for gfx:0
> 
> Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
> 5.4-rc1-ipc from few days ago, the earlier versions had still issues.

I have seen there has been a new version today and I'll try that one asap.

> 
>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
>> [  304.140363] clock-controller:clk:0000:0: failed to enable
>> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
> 
> Hmm no idea what might be up with this one. Did some clkctrl clock
> fixes maybe cause a regression here? Tero do you have any ideas?

BR and thanks,
Nikolaus

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tero Kristo]

On 07/10/2019 18:52, Tony Lindgren wrote:
> Hi,
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
>> Hi all,
>> with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived
>> upstream, so we do no longer need them here.
>>
>> Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some
>> more issues:
>> * omap4 build only needs to distinguish between omap4420/30/60 and omap4470,
>>    because the latter has an sgx544 inside and the other sgx540
>>    This is solved by creating a new omap4470.dts
>> * I have added proper reg values and interrupts to the omap4 device
>>    tree node of the sgx (child node of the target-module)
>> * some updates to my sgxdump and sgxdemo scripts (assuming simple
>>    Debian Stretch rootfs)
>> * James Hilliard has contributed a fix for osfunc.c
>> * omap2plus also needs to be configured for STAGING and PREEMPT
>>    to be able to compile the driver
>> * I have added the __always_inline fix [2] which is needed for v5.4 with
>>    CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds)
>>
>> Unfortunately Tero's rstctrl patches did not yet make it upstream (or even
>> linux-next) so I also have a copy in this branch.
>>
>> Results of first testing are:
>> * OMAP3530 (OpenPandora, BeagleBoard C): fails with
>> [  559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed
>>
>> * DM3730 (GTA04, BeagleBoard XM): kernel module loads
>>
>> * OMAP4460 (Pandaboard ES): kernel module loads
>>
>> * AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
>> [  204.246706] omap_reset_deassert: timedout waiting for gfx:0
> 
> Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
> 5.4-rc1-ipc from few days ago, the earlier versions had still issues.

Yeah, this one should be fixed now.

> 
>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
>> [  304.140363] clock-controller:clk:0000:0: failed to enable
>> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
> 
> Hmm no idea what might be up with this one. Did some clkctrl clock
> fixes maybe cause a regression here? Tero do you have any ideas?

So, this one I am not too sure, I haven't looked at omap5 graphics 
clocking. I don't think it has anything to do with reset handling though.

Is there some simple way to try this out on board; without PVR module 
that is?

-Tero

> 
>> * OMAP5 with omap2plus_defconfig:
>> root@letux:~# echo on > $(find /sys -name control | grep \/5600)
>> [  213.490926] clock-controller:clk:0000:0: failed to enable
>> root@letux:~#
>>
>> * pvrsrvctl --start --no-module:
>>    reports (where the kernel module loads) that the uKernel does not run
>>
>> So I have several ideas what the reasons for the problems on the non-omap5
>> devices could be:
>> * initial code may have some omap5 specific hack inside
>> * or has omap5 specific magic constants
>> * uKernel may "know" on which platform it runs and
>>    we would need differently patched user-space code
>>    for each one
>> * omap5 has a dual core sgx544 while the other
>>    have single core
>> * the register address translation is not yet correct and
>>    this inhibits communicating of the user-space libs
>>    with the uKernel
>>
>> Maybe, if someone can point me to a complete and working BeagleBone source
>> tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare
>> code and address setup to find what makes the difference.
> 
> Regards,
> 
> Tony
> 
>> [1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr
>> [2]: https://lkml.org/lkml/2019/10/2/201

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

Hi Tero,

> Am 07.10.2019 um 21:18 schrieb Tero Kristo <t-kristo@ti.com>:
> 
> On 07/10/2019 18:52, Tony Lindgren wrote:
>> Hi,
>> * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
>> Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
>> 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
> 
> Yeah, this one should be fixed now.

Ok! Will try asap.

> 
>>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
>>> [  304.140363] clock-controller:clk:0000:0: failed to enable
>>> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
>> Hmm no idea what might be up with this one. Did some clkctrl clock
>> fixes maybe cause a regression here? Tero do you have any ideas?
> 
> So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
> 
> Is there some simple way to try this out on board; without PVR module that is?

Yes, I have also seen it when just running the commands in the original commit message [1]:

# echo on > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe00	# OCP Revision
0x5600fe00 = 0x40000000
# echo auto > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe10
# rwmem 0x56000024

But I have not yet tested with 5.4-rc2, just 5.4-rc1.

BR and thanks,
Nikolaus

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.4-rc2&id=394534cb07d8f89b6e621e8a1e6da23571725aef

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tero Kristo]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
> Hi Tero,
> 
>> Am 07.10.2019 um 21:18 schrieb Tero Kristo <t-kristo@ti.com>:
>>
>> On 07/10/2019 18:52, Tony Lindgren wrote:
>>> Hi,
>>> * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
>>> Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
>>> 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
>>
>> Yeah, this one should be fixed now.
> 
> Ok! Will try asap.
> 
>>
>>>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
>>>> [  304.140363] clock-controller:clk:0000:0: failed to enable
>>>> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
>>> Hmm no idea what might be up with this one. Did some clkctrl clock
>>> fixes maybe cause a regression here? Tero do you have any ideas?
>>
>> So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
>>
>> Is there some simple way to try this out on board; without PVR module that is?
> 
> Yes, I have also seen it when just running the commands in the original commit message [1]:
> 
> # echo on > $(find /sys -name control | grep \/5600)
> # rwmem 0x5600fe00	# OCP Revision
> 0x5600fe00 = 0x40000000
> # echo auto > $(find /sys -name control | grep \/5600)
> # rwmem 0x5600fe10
> # rwmem 0x56000024
> 
> But I have not yet tested with 5.4-rc2, just 5.4-rc1.

Ok, there is a one liner DTS data fix for this issue, attached.

-Tero

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[-- Attachment #2: 0001-ARM-dts-omap5-fix-gpu_cm-clock-provider-name.patch --]
[-- Type: text/x-patch, Size: 1121 bytes --]

From 57f9fecb167c0ef9f1ae2a1aa93a05ca8add52a2 Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Tue, 8 Oct 2019 10:56:42 +0300
Subject: [PATCH 1/1] ARM: dts: omap5: fix gpu_cm clock provider name

The clkctrl code searches for the parent clockdomain based on the name
of the CM provider node. The introduction of SGX node for omap5 made
the node name for the gpu_cm to be clock-controller. There is no
clockdomain named like this, so the lookup fails. Fix by changing
the node name properly.

Fixes: 394534cb07d8 ("ARM: dts: Configure sgx for omap5")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index 939ec7dfc366..db9885103099 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -1160,7 +1160,7 @@
 		};
 	};
 
-	gpu_cm: clock-controller@1500 {
+	gpu_cm: gpu_cm@1500 {
 		compatible = "ti,omap4-cm";
 		reg = <0x1500 0x100>;
 		#address-cells = <1>;
-- 
2.17.1

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [191008 08:01]:
> On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
> > Hi Tero,
> > 
> > > Am 07.10.2019 um 21:18 schrieb Tero Kristo <t-kristo@ti.com>:
> > > 
> > > On 07/10/2019 18:52, Tony Lindgren wrote:
> > > > Hi,
> > > > * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
> > > > Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
> > > > 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
> > > 
> > > Yeah, this one should be fixed now.
> > 
> > Ok! Will try asap.
> > 
> > > 
> > > > > * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
> > > > > [  304.140363] clock-controller:clk:0000:0: failed to enable
> > > > > [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
> > > > Hmm no idea what might be up with this one. Did some clkctrl clock
> > > > fixes maybe cause a regression here? Tero do you have any ideas?
> > > 
> > > So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
> > > 
> > > Is there some simple way to try this out on board; without PVR module that is?
> > 
> > Yes, I have also seen it when just running the commands in the original commit message [1]:
> > 
> > # echo on > $(find /sys -name control | grep \/5600)
> > # rwmem 0x5600fe00	# OCP Revision
> > 0x5600fe00 = 0x40000000
> > # echo auto > $(find /sys -name control | grep \/5600)
> > # rwmem 0x5600fe10
> > # rwmem 0x56000024
> > 
> > But I have not yet tested with 5.4-rc2, just 5.4-rc1.
> 
> Ok, there is a one liner DTS data fix for this issue, attached.

Arhg OK that thing again.. I must have changed node name while
cleaning up the patch or something. Thanks, will apply into fixes.

Then for v5.5, we should start using custom compatible properties
for the clock controller instances. I'll be posting a patch for that.
Otherwise scripts/checkpatch.pl --strict type clean-up will cause
unexpected issues.

Regards,

Tony

> From 57f9fecb167c0ef9f1ae2a1aa93a05ca8add52a2 Mon Sep 17 00:00:00 2001
> From: Tero Kristo <t-kristo@ti.com>
> Date: Tue, 8 Oct 2019 10:56:42 +0300
> Subject: [PATCH 1/1] ARM: dts: omap5: fix gpu_cm clock provider name
> 
> The clkctrl code searches for the parent clockdomain based on the name
> of the CM provider node. The introduction of SGX node for omap5 made
> the node name for the gpu_cm to be clock-controller. There is no
> clockdomain named like this, so the lookup fails. Fix by changing
> the node name properly.
> 
> Fixes: 394534cb07d8 ("ARM: dts: Configure sgx for omap5")
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/boot/dts/omap54xx-clocks.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi
> index 939ec7dfc366..db9885103099 100644
> --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
> @@ -1160,7 +1160,7 @@
>  		};
>  	};
>  
> -	gpu_cm: clock-controller@1500 {
> +	gpu_cm: gpu_cm@1500 {
>  		compatible = "ti,omap4-cm";
>  		reg = <0x1500 0x100>;
>  		#address-cells = <1>;
> -- 
> 2.17.1
> 

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 08.10.2019 um 10:00 schrieb Tero Kristo <t-kristo@ti.com>:
> 
> On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
>> Hi Tero,
>>> Am 07.10.2019 um 21:18 schrieb Tero Kristo <t-kristo@ti.com>:
>>> 
>>> On 07/10/2019 18:52, Tony Lindgren wrote:
>>>> Hi,
>>>> * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
>>>> Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
>>>> 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
>>> 
>>> Yeah, this one should be fixed now.
>> Ok! Will try asap.
>>> 
>>>>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
>>>>> [  304.140363] clock-controller:clk:0000:0: failed to enable
>>>>> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
>>>> Hmm no idea what might be up with this one. Did some clkctrl clock
>>>> fixes maybe cause a regression here? Tero do you have any ideas?
>>> 
>>> So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
>>> 
>>> Is there some simple way to try this out on board; without PVR module that is?
>> Yes, I have also seen it when just running the commands in the original commit message [1]:
>> # echo on > $(find /sys -name control | grep \/5600)
>> # rwmem 0x5600fe00	# OCP Revision
>> 0x5600fe00 = 0x40000000
>> # echo auto > $(find /sys -name control | grep \/5600)
>> # rwmem 0x5600fe10
>> # rwmem 0x56000024
>> But I have not yet tested with 5.4-rc2, just 5.4-rc1.
> 
> Ok, there is a one liner DTS data fix for this issue, attached.

Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay!

Together with the latest rstcrtl patches, am335x is now better.
No omap_reset_deassert: timedout waiting for gfx:0 any more.

But I can't access the sgx registers and get memory faults. Maybe
my script has a bug and is trying the wrong address. Have to check
with some distance...

I have also tested omap3630 and omap4460 and they are not worse,
but also not better. So I think the foundation for sgx clock and
reset is now ok.

BR and thanks,
Nikolaus

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> 
>> Am 08.10.2019 um 10:00 schrieb Tero Kristo <t-kristo@ti.com>:
>> 
>> On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
>>> Hi Tero,
>>>> Am 07.10.2019 um 21:18 schrieb Tero Kristo <t-kristo@ti.com>:
>>>> 
>>>> On 07/10/2019 18:52, Tony Lindgren wrote:
>>>>> Hi,
>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
>>>>> Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
>>>>> 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
>>>> 
>>>> Yeah, this one should be fixed now.
>>> Ok! Will try asap.
>>>> 
>>>>>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
>>>>>> [  304.140363] clock-controller:clk:0000:0: failed to enable
>>>>>> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
>>>>> Hmm no idea what might be up with this one. Did some clkctrl clock
>>>>> fixes maybe cause a regression here? Tero do you have any ideas?
>>>> 
>>>> So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
>>>> 
>>>> Is there some simple way to try this out on board; without PVR module that is?
>>> Yes, I have also seen it when just running the commands in the original commit message [1]:
>>> # echo on > $(find /sys -name control | grep \/5600)
>>> # rwmem 0x5600fe00	# OCP Revision
>>> 0x5600fe00 = 0x40000000
>>> # echo auto > $(find /sys -name control | grep \/5600)
>>> # rwmem 0x5600fe10
>>> # rwmem 0x56000024
>>> But I have not yet tested with 5.4-rc2, just 5.4-rc1.
>> 
>> Ok, there is a one liner DTS data fix for this issue, attached.
> 
> Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay!
> 
> Together with the latest rstcrtl patches, am335x is now better.
> No omap_reset_deassert: timedout waiting for gfx:0 any more.
> 
> But I can't access the sgx registers and get memory faults. Maybe
> my script has a bug and is trying the wrong address. Have to check
> with some distance...

Now I have done more tests on am335x. It is not my script but something else.

Trying to read 0x5600fe00 after doing

echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control

gives page faults.

When trying to load the kernel driver, the omap_reset_deassert message has
gone but the driver does no initialize:

root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
[   45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
root@letux:~#

Here is the CM/PM register dump after enabling power/control

*** SGX Register Dump ***
0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL
0x44E00904 00050000 CM_GFX_GFX_CLKCTRL
0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR
0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL
0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL
0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK
0x44E01100 00060047 PM_GFX_PWRSTCTRL
0x44E01104 00000001 RM_GFX_RSTCTRL
0x44E01110 00000037 PM_GFX_PWRSTST

BR,
Nikolaus

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tero Kristo]

On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
> 
>> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>
>>
>>> Am 08.10.2019 um 10:00 schrieb Tero Kristo <t-kristo@ti.com>:
>>>
>>> On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
>>>> Hi Tero,
>>>>> Am 07.10.2019 um 21:18 schrieb Tero Kristo <t-kristo@ti.com>:
>>>>>
>>>>> On 07/10/2019 18:52, Tony Lindgren wrote:
>>>>>> Hi,
>>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [191005 16:59]:
>>>>>> Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
>>>>>> 5.4-rc1-ipc from few days ago, the earlier versions had still issues.
>>>>>
>>>>> Yeah, this one should be fixed now.
>>>> Ok! Will try asap.
>>>>>
>>>>>>> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
>>>>>>> [  304.140363] clock-controller:clk:0000:0: failed to enable
>>>>>>> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)
>>>>>> Hmm no idea what might be up with this one. Did some clkctrl clock
>>>>>> fixes maybe cause a regression here? Tero do you have any ideas?
>>>>>
>>>>> So, this one I am not too sure, I haven't looked at omap5 graphics clocking. I don't think it has anything to do with reset handling though.
>>>>>
>>>>> Is there some simple way to try this out on board; without PVR module that is?
>>>> Yes, I have also seen it when just running the commands in the original commit message [1]:
>>>> # echo on > $(find /sys -name control | grep \/5600)
>>>> # rwmem 0x5600fe00	# OCP Revision
>>>> 0x5600fe00 = 0x40000000
>>>> # echo auto > $(find /sys -name control | grep \/5600)
>>>> # rwmem 0x5600fe10
>>>> # rwmem 0x56000024
>>>> But I have not yet tested with 5.4-rc2, just 5.4-rc1.
>>>
>>> Ok, there is a one liner DTS data fix for this issue, attached.
>>
>> Yes, have tested and it fixes omap5. I have the 3D demo running again on the Pyra. Yay!
>>
>> Together with the latest rstcrtl patches, am335x is now better.
>> No omap_reset_deassert: timedout waiting for gfx:0 any more.
>>
>> But I can't access the sgx registers and get memory faults. Maybe
>> my script has a bug and is trying the wrong address. Have to check
>> with some distance...
> 
> Now I have done more tests on am335x. It is not my script but something else.
> 
> Trying to read 0x5600fe00 after doing
> 
> echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
> 
> gives page faults.
> 
> When trying to load the kernel driver, the omap_reset_deassert message has
> gone but the driver does no initialize:
> 
> root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
> [   45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
> root@letux:~#
> 
> Here is the CM/PM register dump after enabling power/control
> 
> *** SGX Register Dump ***
> 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL
> 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL
> 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR
> 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL
> 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL
> 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK
> 0x44E01100 00060047 PM_GFX_PWRSTCTRL
> 0x44E01104 00000001 RM_GFX_RSTCTRL
> 0x44E01110 00000037 PM_GFX_PWRSTST

Are you sure you have the graphics node properly applied in your kernel?

As you can see the RM_GFX_RSTCTRL is still asserted (it should be zero 
so that you can access the module) and the CM_GFX_GFX_CLKCTRL is also 
disabled (bits 0-1 are 0, should be 2 in the working case.)

It works for me with my branch + the single am33xx patch from Tony.

-Tero

> 
> BR,
> Nikolaus
> 
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 09.10.2019 um 15:55 schrieb Tero Kristo <t-kristo@ti.com>:
> 
> On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
>>> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>> 
>>> 
>>> But I can't access the sgx registers and get memory faults. Maybe
>>> my script has a bug and is trying the wrong address. Have to check
>>> with some distance...
>> Now I have done more tests on am335x. It is not my script but something else.
>> Trying to read 0x5600fe00 after doing
>> echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
>> gives page faults.
>> When trying to load the kernel driver, the omap_reset_deassert message has
>> gone but the driver does no initialize:
>> root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
>> [   45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
>> root@letux:~#
>> Here is the CM/PM register dump after enabling power/control
>> *** SGX Register Dump ***
>> 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL
>> 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL
>> 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR
>> 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL
>> 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL
>> 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK
>> 0x44E01100 00060047 PM_GFX_PWRSTCTRL
>> 0x44E01104 00000001 RM_GFX_RSTCTRL
>> 0x44E01110 00000037 PM_GFX_PWRSTST
> 
> Are you sure you have the graphics node properly applied in your kernel?

Not really... There are several patch sets which seem to be necessary
(to support all omap variants) and I am not sure if I have them all and correctly.

I have collected these patches on top of v5.4-rc2:

272d7200c77a ARM: dts: omap5: fix gpu_cm clock provider name
96fa23010f2a dt-bindings: omap: add new binding for PRM instances
a164172c1f40 soc: ti: add initial PRM driver with reset control support
42a5e4261993 soc: ti: omap-prm: poll for reset complete during de-assert
9237f39716be soc: ti: omap-prm: add support for denying idle for reset clockdomain
bf2ae22e5bcf soc: ti: omap-prm: add omap4 PRM data
be5cb64f10e0 soc: ti: omap-prm: add data for am33xx
86646d7d79be soc: ti: omap-prm: add dra7 PRM data
c3b5455dfd65 soc: ti: omap-prm: add am4 PRM data
e26d4ff7ad15 soc: ti: omap-prm: add omap5 PRM data
66369100d1fc clk: ti: am43xx: drop idlest polling from gfx clock
d96899e143de bus: ti-sysc: re-order reset and main clock controls
45071446bd05 bus: ti-sysc: drop the extra hardreset during init
0da134c3aa9d bus: ti-sysc: avoid toggling power state of module during probe
17b70c96b539 ARM: OMAP2+: pdata-quirks: add PRM data for reset support
af81a68c65d7 clk: ti: clkctrl: fix setting up clkctrl clocks
d7dd7f44bce4 clk: ti: clkctrl: convert to use bit helper macros instead of bitops
42ee8270adfd clk: ti: clkctrl: add new exported API for checking standby info
218b39a8c851 dt-bindings: clk: add omap5 iva clkctrl definitions
41b6c466efde clk: ti: omap5: add IVA subsystem clkctrl data
38cfdebcc2f8 clk: ti: dra7xx: Drop idlest polling from IPU & DSP clkctrl clocks
39e827b0dfe5 clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks
f4584f1e5bff clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks
1c7f5871e5a0 clk: ti: am43xx: drop idlest polling from pruss clkctrl clock
53363c4cfb3d clk: ti: am33xx: drop idlest polling from pruss clkctrl clock
1907994ee9ce ARM: dts: omap5: add IVA clkctrl nodes
8182f3f282de ARM: dts: dra7: add PRM nodes
ff2880fb99c7 ARM: dts: omap4: add PRM nodes
4d49da48c458 ARM: dts: am33xx: Add PRM data
325cffda2b2d ARM: dts: am43xx: Add PRM data
b6ceeb4c5b74 ARM: dts: omap5: Add PRM data
303b7b4bcc60 ARM: dts: dra7: convert IOMMUs to use ti-sysc
d875126d92f7 ARM: dts: dra74x: convert IOMMUs to use ti-sysc
8f699534deb8 ARM: dts: omap4: convert IOMMUs to use ti-sysc
b1ec9e25a686 ARM: dts: omap5: convert IOMMUs to use ti-sysc
e90c0cc1e4a5 ARM: dts: Configure rstctrl reset for SGX


> As you can see the RM_GFX_RSTCTRL is still asserted (it should be zero so that you can access the module) and the CM_GFX_GFX_CLKCTRL is also disabled (bits 0-1 are 0, should be 2 in the working case.)

Ok.

> 
> It works for me with my branch + the single am33xx patch from Tony.

Is there a link so that I can compare with the right version?

BR and thanks,
Nikolaus

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tero Kristo]

On 09/10/2019 17:23, H. Nikolaus Schaller wrote:
> 
>> Am 09.10.2019 um 15:55 schrieb Tero Kristo <t-kristo@ti.com>:
>>
>> On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
>>>> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>>
>>>>
>>>> But I can't access the sgx registers and get memory faults. Maybe
>>>> my script has a bug and is trying the wrong address. Have to check
>>>> with some distance...
>>> Now I have done more tests on am335x. It is not my script but something else.
>>> Trying to read 0x5600fe00 after doing
>>> echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
>>> gives page faults.
>>> When trying to load the kernel driver, the omap_reset_deassert message has
>>> gone but the driver does no initialize:
>>> root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
>>> [   45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
>>> root@letux:~#
>>> Here is the CM/PM register dump after enabling power/control
>>> *** SGX Register Dump ***
>>> 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL
>>> 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL
>>> 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR
>>> 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL
>>> 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL
>>> 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK
>>> 0x44E01100 00060047 PM_GFX_PWRSTCTRL
>>> 0x44E01104 00000001 RM_GFX_RSTCTRL
>>> 0x44E01110 00000037 PM_GFX_PWRSTST
>>
>> Are you sure you have the graphics node properly applied in your kernel?
> 
> Not really... There are several patch sets which seem to be necessary
> (to support all omap variants) and I am not sure if I have them all and correctly.
> 
> I have collected these patches on top of v5.4-rc2:
> 
> 272d7200c77a ARM: dts: omap5: fix gpu_cm clock provider name
> 96fa23010f2a dt-bindings: omap: add new binding for PRM instances
> a164172c1f40 soc: ti: add initial PRM driver with reset control support
> 42a5e4261993 soc: ti: omap-prm: poll for reset complete during de-assert
> 9237f39716be soc: ti: omap-prm: add support for denying idle for reset clockdomain
> bf2ae22e5bcf soc: ti: omap-prm: add omap4 PRM data
> be5cb64f10e0 soc: ti: omap-prm: add data for am33xx
> 86646d7d79be soc: ti: omap-prm: add dra7 PRM data
> c3b5455dfd65 soc: ti: omap-prm: add am4 PRM data
> e26d4ff7ad15 soc: ti: omap-prm: add omap5 PRM data
> 66369100d1fc clk: ti: am43xx: drop idlest polling from gfx clock

You should have similar patch as above for am33xx. Otherwise it will 
probably fail probing the ti-sysc, resulting in the failure you see.

-Tero

> d96899e143de bus: ti-sysc: re-order reset and main clock controls
> 45071446bd05 bus: ti-sysc: drop the extra hardreset during init
> 0da134c3aa9d bus: ti-sysc: avoid toggling power state of module during probe
> 17b70c96b539 ARM: OMAP2+: pdata-quirks: add PRM data for reset support
> af81a68c65d7 clk: ti: clkctrl: fix setting up clkctrl clocks
> d7dd7f44bce4 clk: ti: clkctrl: convert to use bit helper macros instead of bitops
> 42ee8270adfd clk: ti: clkctrl: add new exported API for checking standby info
> 218b39a8c851 dt-bindings: clk: add omap5 iva clkctrl definitions
> 41b6c466efde clk: ti: omap5: add IVA subsystem clkctrl data
> 38cfdebcc2f8 clk: ti: dra7xx: Drop idlest polling from IPU & DSP clkctrl clocks
> 39e827b0dfe5 clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks
> f4584f1e5bff clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks
> 1c7f5871e5a0 clk: ti: am43xx: drop idlest polling from pruss clkctrl clock
> 53363c4cfb3d clk: ti: am33xx: drop idlest polling from pruss clkctrl clock
> 1907994ee9ce ARM: dts: omap5: add IVA clkctrl nodes
> 8182f3f282de ARM: dts: dra7: add PRM nodes
> ff2880fb99c7 ARM: dts: omap4: add PRM nodes
> 4d49da48c458 ARM: dts: am33xx: Add PRM data
> 325cffda2b2d ARM: dts: am43xx: Add PRM data
> b6ceeb4c5b74 ARM: dts: omap5: Add PRM data
> 303b7b4bcc60 ARM: dts: dra7: convert IOMMUs to use ti-sysc
> d875126d92f7 ARM: dts: dra74x: convert IOMMUs to use ti-sysc
> 8f699534deb8 ARM: dts: omap4: convert IOMMUs to use ti-sysc
> b1ec9e25a686 ARM: dts: omap5: convert IOMMUs to use ti-sysc
> e90c0cc1e4a5 ARM: dts: Configure rstctrl reset for SGX
> 
> 
>> As you can see the RM_GFX_RSTCTRL is still asserted (it should be zero so that you can access the module) and the CM_GFX_GFX_CLKCTRL is also disabled (bits 0-1 are 0, should be 2 in the working case.)
> 
> Ok.
> 
>>
>> It works for me with my branch + the single am33xx patch from Tony.
> 
> Is there a link so that I can compare with the right version?
> 
> BR and thanks,
> Nikolaus
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 09.10.2019 um 18:34 schrieb Tero Kristo <t-kristo@ti.com>:
> 
> On 09/10/2019 17:23, H. Nikolaus Schaller wrote:
>>> Am 09.10.2019 um 15:55 schrieb Tero Kristo <t-kristo@ti.com>:
>>> 
>>> On 09/10/2019 15:53, H. Nikolaus Schaller wrote:
>>>>> Am 08.10.2019 um 22:15 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>>> 
>>>>> 
>>>>> But I can't access the sgx registers and get memory faults. Maybe
>>>>> my script has a bug and is trying the wrong address. Have to check
>>>>> with some distance...
>>>> Now I have done more tests on am335x. It is not my script but something else.
>>>> Trying to read 0x5600fe00 after doing
>>>> echo on > /sys/bus/platform/devices/5600fe00.target-module/power/control
>>>> gives page faults.
>>>> When trying to load the kernel driver, the omap_reset_deassert message has
>>>> gone but the driver does no initialize:
>>>> root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
>>>> [   45.774712] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
>>>> root@letux:~#
>>>> Here is the CM/PM register dump after enabling power/control
>>>> *** SGX Register Dump ***
>>>> 0x44E00900 00000301 CM_GFX_L3_CLKSTCTRL
>>>> 0x44E00904 00050000 CM_GFX_GFX_CLKCTRL
>>>> 0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR
>>>> 0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL
>>>> 0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL
>>>> 0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK
>>>> 0x44E01100 00060047 PM_GFX_PWRSTCTRL
>>>> 0x44E01104 00000001 RM_GFX_RSTCTRL
>>>> 0x44E01110 00000037 PM_GFX_PWRSTST
>>> 
>>> Are you sure you have the graphics node properly applied in your kernel?
>> Not really... There are several patch sets which seem to be necessary
>> (to support all omap variants) and I am not sure if I have them all and correctly.
>> I have collected these patches on top of v5.4-rc2:
>> 272d7200c77a ARM: dts: omap5: fix gpu_cm clock provider name
>> 96fa23010f2a dt-bindings: omap: add new binding for PRM instances
>> a164172c1f40 soc: ti: add initial PRM driver with reset control support
>> 42a5e4261993 soc: ti: omap-prm: poll for reset complete during de-assert
>> 9237f39716be soc: ti: omap-prm: add support for denying idle for reset clockdomain
>> bf2ae22e5bcf soc: ti: omap-prm: add omap4 PRM data
>> be5cb64f10e0 soc: ti: omap-prm: add data for am33xx
>> 86646d7d79be soc: ti: omap-prm: add dra7 PRM data
>> c3b5455dfd65 soc: ti: omap-prm: add am4 PRM data
>> e26d4ff7ad15 soc: ti: omap-prm: add omap5 PRM data
>> 66369100d1fc clk: ti: am43xx: drop idlest polling from gfx clock
> 
> You should have similar patch as above for am33xx. Otherwise it will probably fail probing the ti-sysc, resulting in the failure you see.
> 
> -Tero
> 
>> d96899e143de bus: ti-sysc: re-order reset and main clock controls
>> 45071446bd05 bus: ti-sysc: drop the extra hardreset during init
>> 0da134c3aa9d bus: ti-sysc: avoid toggling power state of module during probe
>> 17b70c96b539 ARM: OMAP2+: pdata-quirks: add PRM data for reset support
>> af81a68c65d7 clk: ti: clkctrl: fix setting up clkctrl clocks
>> d7dd7f44bce4 clk: ti: clkctrl: convert to use bit helper macros instead of bitops
>> 42ee8270adfd clk: ti: clkctrl: add new exported API for checking standby info
>> 218b39a8c851 dt-bindings: clk: add omap5 iva clkctrl definitions
>> 41b6c466efde clk: ti: omap5: add IVA subsystem clkctrl data
>> 38cfdebcc2f8 clk: ti: dra7xx: Drop idlest polling from IPU & DSP clkctrl clocks
>> 39e827b0dfe5 clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks
>> f4584f1e5bff clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks
>> 1c7f5871e5a0 clk: ti: am43xx: drop idlest polling from pruss clkctrl clock
>> 53363c4cfb3d clk: ti: am33xx: drop idlest polling from pruss clkctrl clock

so the pattern of ^^^ but for gfx clock?

Yes, there seems to be

[PATCH 1/2] clk: ti: am33xx: drop idlest polling from gfx clock

which I am missing. Most likely, I accidentally did download from
patchwork just a single patch (am43xx) and not the series...

With this patch added, I now have access to the sgx registers:

root@letux:~# ./sgxdump 
*** SGX Register Dump ***
0x44E00900 00000302 CM_GFX_L3_CLKSTCTRL
0x44E00904 00040002 CM_GFX_GFX_CLKCTRL
0x44E0090c 00000002 CM_GFX_L4LS_GFX_CLKSTCTR
0x44E00910 00030000 CM_GFX_MMUCFG_CLKCTRL
0x44E00914 00030000 CM_GFX_MMUDATA_CLKCTRL
0x44E0052c 00000000 CM_DPLL.CLKSEL_GFX_FCLK
0x44E01100 00060047 PM_GFX_PWRSTCTRL
0x44E01104 00000000 RM_GFX_RSTCTRL
0x44E01110 00000037 PM_GFX_PWRSTST
0x5600fe14 00000000 SGX_CORE_VERSION
0x5600fe00 40000000 OCP_REVISION
0x5600fe04 00000005 OCP_HWINFO
0x5600fe10 00000028 OCP_SYSCONFIG
0x5600fe24 00000000 OCP_IRQSTATUS_RA_0
0x5600fe28 00000000 OCP_IRQSTATUS_RA_1
0x5600fe2c 00000000 OCP_IRQSTATUS_RA_2
0x5600fe30 00000000 OCP_IRQSTATUS_0
0x5600fe34 00000000 OCP_IRQSTATUS_1
0x5600fe38 00000000 OCP_IRQSTATUS_2
0x5600fe3c 00000000 OCP_IRQENABLE_SET_0
0x5600fe40 00000000 OCP_IRQENABLE_SET_1
0x5600fe44 00000000 OCP_IRQENABLE_SET_2
0x5600fe48 00000000 OCP_IRQENABLE_CLR_0
0x5600fe4c 00000000 OCP_IRQENABLE_CLR_1
0x5600fe50 00000000 OCP_IRQENABLE_CLR_2
0x5600ff00 00000014 OCP_PAGE_CONFIG
0x5600ff04 00000000 OCP_INTERRUPT_EVENT
0x5600ff08 00000000 OCP_DEBUG_CONFIG
0x5600ff0c 023fe407 OCP_DEBUG_STATUS
0x56000010 01120000 SGX_CORE_VERSION
0x56000014 00010205 SGX_CORE_REVISION
root@letux:~# root@letux:~# modprobe pvrsrvkm_omap_am335x_sgx530_125
[  282.569941] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
[  282.673908] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1
root@letux:~# 

The 0112 of SGX_CORE_VERSION is sgx530 and 010205 is revision -125
as expected.

Starting pvr still reports that the ukernel can not be loaded,
but that is somewhere in the pvrsrvkm code that my driver
only likes the omap5+sgx544 at the moment.

Latest v5.4-rc2 code is here: [1]

Thanks and BR,
Nikolaus

[1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr

Re: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

Hi,

> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> So I have several ideas what the reasons for the problems on the non-omap5
> devices could be:
> * initial code may have some omap5 specific hack inside
> * or has omap5 specific magic constants
> * uKernel may "know" on which platform it runs and
>  we would need differently patched user-space code
>  for each one
> * omap5 has a dual core sgx544 while the other
>  have single core
> * the register address translation is not yet correct and
>  this inhibits communicating of the user-space libs
>  with the uKernel
> 
> Maybe, if someone can point me to a complete and working BeagleBone source
> tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare
> code and address setup to find what makes the difference.

I have found the following description, followed all steps, and it works:

http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019

So with this, I have got a working user-space setup for BeagleBone and some working
pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.

Symbols of the kernel module are not stripped, so that I can indirectly compare
some build/configure options.

root@arm:~# uname -a
Linux arm 4.4.155-ti-r155 #1 SMP Thu May 23 06:00:18 UTC 2019 armv7l GNU/Linux
root@arm:~# ls -l /lib/modules/4.4.155-ti-r155/extra/ti335x/pvrsrvkm.ko
-rw-r--r-- 1 root root 408084 May 23 06:46 /lib/modules/4.4.155-ti-r155/extra/ti335x/pvrsrvkm.ko
root@arm:~# dmesg|fgrep -i pvr
[   24.589384] pvrsrvkm: loading out-of-tree module taints kernel.
[   25.051602] [drm] Initialized pvr 1.14.3699939 20110701 on minor 1
root@arm:~# sudo /usr/bin/pvrsrvctl --start --no-module
root@arm:~# cat /proc/pvr/version
Version SGX_DDK sgxddk MAIN@3699939 (release) omap_linux
System Version String: SGX revision = 125
root@arm:~# 

For comparison, I have:

root@letux:~# uname -a
Linux letux 5.4.0-rc2-letux+ #1161 SMP PREEMPT Wed Oct 9 19:05:21 CEST 2019 armv7l GNU/Linux
root@letux:~# ls -l /lib/modules/5.4.0-rc2-letux+/kernel/drivers/staging/pvr/1.14.3699939/eurasia_km/pvrsrvkm_omap_am335x_sgx530_125.ko
-rw-r--r-- 1 1002 root 4751504 Oct  9 17:09 /lib/modules/5.4.0-rc2-letux+/kernel/drivers/staging/pvr/1.14.3699939/eurasia_km/pvrsrvkm_omap_am335x_sgx530_125.ko
root@letux:~# dmesg|fgrep -i pvr
[  119.376338] pvrsrvkm_omap_am335x_sgx530_125: module is from the staging directory, the quality is unknown, you have been warned.
[  119.478943] [drm] Initialized pvr 1.14.3699939 20110701 for 56000000.sgx on minor 1
root@letux:~# /usr/bin/pvrsrvctl --start --no-module
[  238.178801] PVR_K: UM DDK-(3699939) and KM DDK-(3699939) match. [ OK ]
PVR:(Error): LoaduKernelProgram : SGX ukernel program Device Addr: 0xe400000 invalid alignment
PVR:(Error): SetupuKernel : Failed to load uKernel program
PVR:(Error): SrvInit: Initialisation for device of class 0, type 7, index 0, failed (1) [0, ]
[  238.667915] PVR_K:(Error): BridgedDispatchKM: Initialisation failed.  Driver unusable.
PVR:(Error): PVRSRVBridgeCall: Failed to access device.  Function ID:3223086862 (strerror returns no value.). [0, ]
/usr/bin/pvrsrvctl: SrvInit failed (already initialized?) (err=PVRSRV_ERROR_OUT_OF_MEMORY - Unable to allocate required memory)
root@letux:~# 

First observations:
* pvrsrvkm.ko is a little smaller (may be a result of compiler and build options)
* both taint the kernel, as expected
* they are exactly the same DDK release 1.14.3699939
* my version is a little more verbose
* but fails loading the uKernel

What I don't have yet is the full source code or build recipe for the specific
4.4.155-ti-r155 pvrsrvkm.ko from TI.

But even without having this yet, I can start experiments by replacing
kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.

BR,
Nikolaus

Re: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[H. Nikolaus Schaller]

> Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi,
> 
>> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> I have found the following description, followed all steps, and it works:
> 
> http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019
> 
> So with this, I have got a working user-space setup for BeagleBone and some working
> pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.

> What I don't have yet is the full source code or build recipe for the specific
> 4.4.155-ti-r155 pvrsrvkm.ko from TI.
> 
> But even without having this yet, I can start experiments by replacing
> kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.

Good news:

after making a Hybrid SD image of the setup described above and replacing the
4.4.155-ti-r155 kernel with its pvrsrvkm.ko by my own 5.4-rc2 kernel and pvrsrvkm,
I was able to start the pvrsrv uKernel. And run the gles1test1 on beaglebone
(without LCD but also without errors).

With this knowledge I could adapt my user-space. There are indeed different
non-free binaries for sgx530, sgx540, sgx544. And SGX needs enough coherent memory.
So I could make a completely self-built kernel and rootfs (using the git clone from
ti for the firmware + make install) run on BeagleBone.

Here is a quickly taken video:

https://youtu.be/jFCPR_EvtjY

With the same setup, I can now also load the kernel driver and run pvrsrvctl on
DM3730 without errors, but the gles1test1 reports some error and fails to run.
Maybe something in the video subsystem or memory mapping is still wrong.

Unfortunately, the same setup does not run on omap5. It looks like there are different
releases for the non-free binaries and I have to pick the right one.

On BBB the version I could make running is branch ti-img-sgx/1.14.3699939_k4.4 from
git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git. Target ti335x works while
target jacinto6evm fails for OMAP5. A diff on the binaries for e.g. pvrsrvctl shows
that they are different.

If you want to repeat this setup and my instructions are too imprecise, please
ask.

So in summary this means:
* the common foundation (clock, reset, power etc.) setup is working - thanks to Tero, Tony and others
* I have added device tree nodes for each SoC type to define sgx registers, interrupts, compatible etc.
* compiling SoC specific kernel module variants from single source tree works
* the work can already be demoed on BBB and OMAP5 Pyra (using different user-space binaries)

Basically I am now ready to post an RFC for the sgx child device nodes together
with a bindings document [1]. But I am not sure if I should better wait until
really all underlaying prm+rtsctl+syscon+idlest-polling patches by Tero and Tony [2]
have matured in linux-next and have arrived in v5.5-rc1. Would be short before Xmas.

Independent of low level patches, we all have to discuss how we want to get the GPLed
kernel driver [3] into mainline drivers/staging. This likely needs more cleanup before
it can be proposed.

BR,
Nikolaus

[1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue-v5
[2]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-sysc-prm-gfx
[3]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/latest-pvr

Re: [Letux-kernel] Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [191014 09:12]:
> 
> > Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > 
> > Hi,
> > 
> >> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > 
> > I have found the following description, followed all steps, and it works:
> > 
> > http://blog.0xpebbles.org/PowerVR-SGX-on-the-beaglebone-black-in-2019
> > 
> > So with this, I have got a working user-space setup for BeagleBone and some working
> > pvrsrvkm.ko module (kernel 4.4.155-ti-r155) for evaluation.
> 
> > What I don't have yet is the full source code or build recipe for the specific
> > 4.4.155-ti-r155 pvrsrvkm.ko from TI.
> > 
> > But even without having this yet, I can start experiments by replacing
> > kernel and pvrsrvkm.ko with mine. This should allow to gain new insights.
> 
> Good news:
> 
> after making a Hybrid SD image of the setup described above and replacing the
> 4.4.155-ti-r155 kernel with its pvrsrvkm.ko by my own 5.4-rc2 kernel and pvrsrvkm,
> I was able to start the pvrsrv uKernel. And run the gles1test1 on beaglebone
> (without LCD but also without errors).
> 
> With this knowledge I could adapt my user-space. There are indeed different
> non-free binaries for sgx530, sgx540, sgx544. And SGX needs enough coherent memory.
> So I could make a completely self-built kernel and rootfs (using the git clone from
> ti for the firmware + make install) run on BeagleBone.
> 
> Here is a quickly taken video:
> 
> https://youtu.be/jFCPR_EvtjY

Nice :)

> With the same setup, I can now also load the kernel driver and run pvrsrvctl on
> DM3730 without errors, but the gles1test1 reports some error and fails to run.
> Maybe something in the video subsystem or memory mapping is still wrong.
> 
> Unfortunately, the same setup does not run on omap5. It looks like there are different
> releases for the non-free binaries and I have to pick the right one.
> 
> On BBB the version I could make running is branch ti-img-sgx/1.14.3699939_k4.4 from
> git://git.ti.com/graphics/omap5-sgx-ddk-um-linux.git. Target ti335x works while
> target jacinto6evm fails for OMAP5. A diff on the binaries for e.g. pvrsrvctl shows
> that they are different.
> 
> If you want to repeat this setup and my instructions are too imprecise, please
> ask.
> 
> So in summary this means:
> * the common foundation (clock, reset, power etc.) setup is working - thanks to Tero, Tony and others
> * I have added device tree nodes for each SoC type to define sgx registers, interrupts, compatible etc.
> * compiling SoC specific kernel module variants from single source tree works
> * the work can already be demoed on BBB and OMAP5 Pyra (using different user-space binaries)
> 
> Basically I am now ready to post an RFC for the sgx child device nodes together
> with a bindings document [1]. But I am not sure if I should better wait until
> really all underlaying prm+rtsctl+syscon+idlest-polling patches by Tero and Tony [2]
> have matured in linux-next and have arrived in v5.5-rc1. Would be short before Xmas.

I think you've already proven that we can have a generic binding for the
sgx using standard properties :) So AFAIK, there's nothing stopping you
from posting the binding and dts changes for review for v5.5.

> Independent of low level patches, we all have to discuss how we want to get the GPLed
> kernel driver [3] into mainline drivers/staging. This likely needs more cleanup before
> it can be proposed.

You probably need a shell script using sed or something to get rid of the
crazy directory path for the kernel driver :) Just make it something like:

drivers/staging/pvr

Then if you have a script doing the directory path conversion, you can
still convert and diff against any other prv branches you may find.

And you can get rid of all the LINUX_VERSION_CODE stuff too for the
mainline kernel.

Regards,

Tony


> [1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue-v5
> [2]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-sysc-prm-gfx
> [3]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/latest-pvr
>