From: Tony Lindgren <tony@atomide.com>
To: Nishanth Menon <nm@ti.com>
Cc: Suman Anna <s-anna@ti.com>,
devicetree@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
Date: Mon, 4 May 2015 09:31:14 -0700 [thread overview]
Message-ID: <20150504163113.GP24469@atomide.com> (raw)
In-Reply-To: <553A8C68.5080903@ti.com>
* Nishanth Menon <nm@ti.com> [150424 11:34]:
> On 04/24/2015 12:54 PM, Suman Anna wrote:
> > The L3 Error handling on OMAP5 for the most part is very similar
> > to that of OMAP4, and had leveraged common data structures and
> > register layout definitions so far. Upon closer inspection, there
> > are a few minor differences causing an incorrect decoding and
> > reporting of the master NIU upon an error:
> >
> > 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
> > 11 bits on OMAP5 as against 8 bits on OMAP4, with the master
> > NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
> > field.
> > 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
> > input sources on OMAP5. The common DEBUGSS source is at a
> > different input on each SoC.
> >
> > Fix the above issues by using a OMAP5-specific compatible property
> > and using SoC-specific data where there are differences.
> >
> > Cc: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Suman Anna <s-anna@ti.com>
...
> If tony does not mind dts+driver patch, then except for the above comment:
>
> Acked-by: Nishanth Menon <nm@ti.com>
Looks OK to me for a fix. In general we want to have the .dts
changes separated from the driver changes though.
Applying into omap-for-v4.1/fixes.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
Date: Mon, 4 May 2015 09:31:14 -0700 [thread overview]
Message-ID: <20150504163113.GP24469@atomide.com> (raw)
In-Reply-To: <553A8C68.5080903@ti.com>
* Nishanth Menon <nm@ti.com> [150424 11:34]:
> On 04/24/2015 12:54 PM, Suman Anna wrote:
> > The L3 Error handling on OMAP5 for the most part is very similar
> > to that of OMAP4, and had leveraged common data structures and
> > register layout definitions so far. Upon closer inspection, there
> > are a few minor differences causing an incorrect decoding and
> > reporting of the master NIU upon an error:
> >
> > 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
> > 11 bits on OMAP5 as against 8 bits on OMAP4, with the master
> > NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
> > field.
> > 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
> > input sources on OMAP5. The common DEBUGSS source is at a
> > different input on each SoC.
> >
> > Fix the above issues by using a OMAP5-specific compatible property
> > and using SoC-specific data where there are differences.
> >
> > Cc: Nishanth Menon <nm@ti.com>
> > Signed-off-by: Suman Anna <s-anna@ti.com>
...
> If tony does not mind dts+driver patch, then except for the above comment:
>
> Acked-by: Nishanth Menon <nm@ti.com>
Looks OK to me for a fix. In general we want to have the .dts
changes separated from the driver changes though.
Applying into omap-for-v4.1/fixes.
Regards,
Tony
next prev parent reply other threads:[~2015-05-04 16:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 17:54 [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5 Suman Anna
2015-04-24 17:54 ` Suman Anna
2015-04-24 18:33 ` Nishanth Menon
2015-04-24 18:33 ` Nishanth Menon
2015-04-24 19:10 ` Suman Anna
2015-04-24 19:10 ` Suman Anna
2015-04-24 19:38 ` Nishanth Menon
2015-04-24 19:38 ` Nishanth Menon
2015-04-24 19:54 ` Suman Anna
2015-04-24 19:54 ` Suman Anna
2015-04-24 19:55 ` Nishanth Menon
2015-04-24 19:55 ` Nishanth Menon
2015-05-04 16:31 ` Tony Lindgren [this message]
2015-05-04 16:31 ` Tony Lindgren
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=20150504163113.GP24469@atomide.com \
--to=tony@atomide.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=s-anna@ti.com \
/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.