[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140617073552.GM17845@atomide.com>
Date: Tue, 17 Jun 2014 00:35:52 -0700
From: Tony Lindgren <tony@...mide.com>
To: Tomi Valkeinen <tomi.valkeinen@...com>
Cc: Felipe Balbi <balbi@...com>,
Benoit Cousson <bcousson@...libre.org>,
Paul Walmsley <paul@...an.com>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
Linux ARM Kernel Mailing List
<linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Sathya Prakash M R <sathyap@...com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data
* Tomi Valkeinen <tomi.valkeinen@...com> [140617 00:10]:
> On 16/06/14 12:22, Tony Lindgren wrote:
> > * Felipe Balbi <balbi@...com> [140613 09:17]:
> >> From: Sathya Prakash M R <sathyap@...com>
> >>
> >> Add DSS hwmod data for AM43xx.
> >>
> >> Cc: Andrew Morton <akpm@...ux-foundation.org>
> >> Acked-by: Rajendra Nayak <rnayak@...com>
> >> Signed-off-by: Sathya Prakash M R <sathyap@...com>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@...com>
> >> Signed-off-by: Felipe Balbi <balbi@...com>
> >> ---
> >>
> >> Note that this patch was originally send on May 9th [1], changes were requested
> >> and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
> >> maintainer again and go no response.
> >>
> >> Without this patch, we cannot get display working on any AM437x devices.
> >>
> >> [1] http://marc.info/?l=linux-arm-kernel&m=139963677925227&w=2
> >> [2] http://marc.info/?l=linux-arm-kernel&m=140049799425512&w=2
> >> [3] http://marc.info/?l=linux-arm-kernel&m=140117232826754&w=2
> >>
> >> arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++++++++++++++++++++++++++++++
> >> arch/arm/mach-omap2/prcm43xx.h | 1 +
> >> 2 files changed, 99 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> index 5c2cc80..d2a7b6d 100644
> >> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> >> @@ -19,6 +19,8 @@
> >> #include "omap_hwmod.h"
> >> #include "omap_hwmod_33xx_43xx_common_data.h"
> >> #include "prcm43xx.h"
> >> +#include "omap_hwmod_common_data.h"
> >> +
> >>
> >> /* IP blocks */
> >> static struct omap_hwmod am43xx_l4_hs_hwmod = {
> >> @@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
> >> },
> >> };
> >>
> >> +/* Display sub system - DSS */
> >> +
> >> +struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
> >> + .manager_count = 1,
> >> + .has_framedonetv_irq = 0
> >> +};
> >> +
> >> +
> >> +static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
> >> + .rev_offs = 0x0000,
> >> + .sysc_offs = 0x0010,
> >> + .syss_offs = 0x0014,
> >> + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> >> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> >> + .sysc_fields = &omap_hwmod_sysc_type1,
> >> +};
> >
> > Looking at the TRM, "Table 13-43. DISPC_SYSCFG Register Field
> > Descriptions" seems to list the folowing bits available:
> >
> > 13-12 MIDLEMODE
> > 9-8 CLOCK_ACTIVITY
> > 4-3 SIDLEMODE
> > 2 ENWAKEUP
> > 1 SOFTRESET
> > 0 AUTOIDLE
> >
> > Have I missed something or how come we don't define them all
> > as available?
>
> Yes, you're right. I don't see why they shouldn't be there.
>
> > The .idlemodes available values and .sysc_fields seems to match
> > the TRM.
>
> Shouldn't idlemodes also have:
>
> MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART
Oops yes indeed looking at the MIDDLEDMOE values in addition to
to SIDLEMODE.
> I changed the dispc flags to:
>
> .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
> SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
> SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_MIDLEMODE),
> .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
>
> and DSS seems to work fine for me. Then again, I don't think there's any
> proper PM going on (or at least things like debugfs/pm_debug/count shows
> no sensible values), so it could well be that those flags are not even
> used at the moment.
Right. Having these set correctly for devices is pretty much a
requirement for PM to have any chance of working :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists