All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: "Andreas Kemnade" <andreas@kemnade.info>,
	"Patrik Dahlström" <risca@dalakolonin.se>,
	letux-kernel@openphoenux.org, kernel@pyra-handheld.com,
	linux-omap@vger.kernel.org,
	"Péter Ujfalusi" <peter.ujfalusi@gmail.com>
Subject: Re: ABE/AESS on modern kernel: clocks, hwmods etc.
Date: Tue, 5 Sep 2023 09:12:08 +0300	[thread overview]
Message-ID: <20230905061208.GW11676@atomide.com> (raw)
In-Reply-To: <03375B42-C86E-4B37-98C2-C1FBA7AB68B6@goldelico.com>

* H. Nikolaus Schaller <hns@goldelico.com> [230904 18:07]:
> > Am 04.09.2023 um 08:34 schrieb Tony Lindgren <tony@atomide.com>:
> > No idea about this one, but this might be doable with generic pwm code
> > now with the dmtimers. See for example how the ir-rx51 is getting phased
> > away and replaced with the generci pwm ir driver.
> 
> This is not PWM. It writes to some register shared with the AESS DSP and we assume that the
> DSP firmware should be started. I have put Péter on CC, maybe he knows something.

Hmm sorry I somehow thought it was using a dmtimer. There are references to
ABE_GPT5_FCLK to ABE_GPT8_FCLK in the TRM but maybe those are separate
and the driver is not tinkering with the timer register directly hopefully.

> >>> It seems as if clocks and code like omap_hwmod_aess_preprogram() is missing. Especially for the
> >>> omap4 we have found no equivalent to aess_fclk which exists for omap5 and dra7.
> >>> Nowhere is a reference using the abe_iclk node.
> >>> 
> >> for omap4 I guess the 
> >>                        clocks = <&abe_clkctrl OMAP4_AESS_CLKCTRL 0>;
> >> 
> >> in omap4-l4-abe.dtsi should be enough and correcly referencing fclk?
> > 
> > Yeah the clocks chould be there and should use addressing like Andreas is
> > showing.
> 
> Well, according to my analysis the fclk may be there but the iclk is missing or not initialized.
> That could explain why we get L3 problems as soon as we try to start the AESS-DSP.

OK

> The key observation is that the abe_iclk references in the DTS seem to be nowhere referenced
> (which may or may not be an issue):
>
> https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/dts/ti/omap/omap44xx-clocks.dtsi#L509
> https://github.com/goldelico/letux-kernel/blob/letux/aess-v12/arch/arm/boot/dts/ti/omap/omap54xx-clocks.dtsi#L161

So I guess the ick is in the dts the ocp_abe_iclk@528 for omap4 and
abe_iclk@528 for omap5. Seems like the driver should request them, I recall
that the interconnect target module does not need the ick to access sysc
and revision registers.

> The branch where all changes are sitting can be inspected here:
> 
> https://github.com/goldelico/letux-kernel/commits/letux/aess-v12?after=567e9011a67f4ed0824c2989a5d5f73ca0139461+63&branch=letux%2Faess-v12&qualified_name=refs%2Fheads%2Fletux%2Faess-v12
> 
> They are all tagged ARM: DTS: omap4 or omap5.

Hmm the "we don't need separate target modules" patch is wrong, the modules
may have separate clocks and power domains, and flushing a posted write to
one module does not flush write to the other module. This can lead into hard
to track down bugs accessing separate modules. The dts module data I
generated from the hardware AP registers for each SoC so the module ranges
should be correct.

> Hope this helps. Otherwise we have to prepare a cleaned up version of the DTS changes as a patch series.

Yeah nice,

Tony

  parent reply	other threads:[~2023-09-05 15:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53bc74ae-a2d5-40d5-8d51-bc0f062fcd15@email.android.com>
     [not found] ` <45F44D32-E846-4A53-BA20-9C78CD4411F3@goldelico.com>
     [not found]   ` <ZO4SWw/rbJH5Dpbq@dalakolonin.se>
     [not found]     ` <A029FB33-9FBB-4CE5-92D5-597E10B3A032@goldelico.com>
     [not found]       ` <ZPH5Yr3w7ruN/io0@dalakolonin.se>
     [not found]         ` <05B47ED4-CA2C-4754-ABB1-0591E9018E57@goldelico.com>
     [not found]           ` <ZPLYG16mwiwt9G9R@dalakolonin.se>
2023-09-02  7:27             ` ABE/AESS on modern kernel: clocks, hwmods etc H. Nikolaus Schaller
2023-09-02 10:26               ` Andreas Kemnade
2023-09-04  6:34                 ` Tony Lindgren
     [not found]                   ` <03375B42-C86E-4B37-98C2-C1FBA7AB68B6@goldelico.com>
2023-09-05  6:12                     ` Tony Lindgren [this message]
2023-09-05 12:42                       ` H. Nikolaus Schaller
2023-09-05 14:44                         ` Andreas Kemnade
2023-09-05 15:09                           ` H. Nikolaus Schaller
2023-09-05 15:48                             ` H. Nikolaus Schaller
2023-09-05 16:53                               ` H. Nikolaus Schaller
2023-09-06 13:50                         ` Patrik Dahlström

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=20230905061208.GW11676@atomide.com \
    --to=tony@atomide.com \
    --cc=andreas@kemnade.info \
    --cc=hns@goldelico.com \
    --cc=kernel@pyra-handheld.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=peter.ujfalusi@gmail.com \
    --cc=risca@dalakolonin.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.