From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/8] ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors
Date: Wed, 11 Oct 2017 11:41:12 -0700 [thread overview]
Message-ID: <20171011184112.GF4394@atomide.com> (raw)
In-Reply-To: <20170821234818.4755-7-s-anna@ti.com>
* Suman Anna <s-anna@ti.com> [170821 16:48]:
> OMAP5, like OMAP4, also has an IPU and a DSP processor subsystems.
> The relevant hwmod classes and data structures are added for these
> devices.
>
> Do note that these hwmod data strucutures do not have a .modulemode
> field as the devices are managed together with their corresponding
> MMUs. Each of the processor subsystem and its MMU are present within
> the same clock domain and requires the domain be clocked and enabled
> until the last entity is disabled. The module is disabled properly
> during the omap_device_idle processing of the MMU hwmod while
> disabling the MMU.
I think we can make that issue go away, see below.
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -335,6 +335,36 @@ static struct omap_hwmod omap54xx_dmic_hwmod = {
> +/* dsp */
> +static struct omap_hwmod omap54xx_dsp_hwmod = {
> + .name = "dsp",
> + .class = &omap54xx_dsp_hwmod_class,
> + .clkdm_name = "dsp_clkdm",
> + .rst_lines = omap54xx_dsp_resets,
> + .rst_lines_cnt = ARRAY_SIZE(omap54xx_dsp_resets),
> + .main_clk = "dpll_iva_h11x2_ck",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET,
> + .rstctrl_offs = OMAP54XX_RM_DSP_RSTCTRL_OFFSET,
> + .context_offs = OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET,
> + },
> + },
> +};
> +
> +/*
I don't think we should add a second instance for the DSP_CLKCTRL.
We already have mmu_dsp instance and I'm pretty sure this should be
just one parent "ti,sysc-omap4" interconnect target module instance.
Then the MMU and DSP can be children of that node. I think it's set
the same way for all omap4 and later SoCs. So let's wait on
this series until we have this verified.
Tehn for resets, in the long run we can add reset controller support
to the ti-sysc driver and then the MMU driver can do the reset with
device_reset(dev->parent). Also a separate resetctrl driver is needed
that the ti-sysc driver can request.
But yeah sorry no immediate solution available for the reset part.
Regards,
Tony
next prev parent reply other threads:[~2017-10-11 18:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 23:48 [PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs Suman Anna
2017-08-21 23:48 ` [PATCH 1/8] ARM: DRA7: hwmod data: Add MMU data for IPUs Suman Anna
2017-08-21 23:48 ` [PATCH 2/8] ARM: DRA7: hwmod data: Add MMU data for DSPs Suman Anna
2017-08-21 23:48 ` [PATCH 3/8] ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs Suman Anna
2017-08-21 23:48 ` [PATCH 4/8] ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs Suman Anna
2017-08-21 23:48 ` [PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods Suman Anna
2017-08-22 17:37 ` Tony Lindgren
2017-08-22 18:44 ` Suman Anna
2017-08-22 19:24 ` Tony Lindgren
2017-08-22 20:54 ` Suman Anna
2017-08-21 23:48 ` [PATCH 6/8] ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors Suman Anna
2017-10-11 18:41 ` Tony Lindgren [this message]
2017-08-21 23:48 ` [PATCH 7/8] ARM: DRA7: hwmod_data: Add data for IPUs Suman Anna
2017-08-21 23:48 ` [PATCH 8/8] ARM: DRA7: hwmod_data: Add data for DSPs Suman Anna
2017-09-22 17:18 ` [PATCH 0/8] Add hwmod data for IPU & DSP processors/MMUs Suman Anna
2017-09-22 17:51 ` Tony Lindgren
2017-09-22 21:07 ` Suman Anna
2017-09-22 21:19 ` Tony Lindgren
2017-10-12 5:50 ` Tero Kristo
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=20171011184112.GF4394@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).