[PATCH 3.12 038/113] ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup
From: Vineet Gupta
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit a524c218bc94c705886a0e0fedeee45d1931da32 upstream.
Reported-by: Jo-Philipp Wich
Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
Cc: linux-ker...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Linus Torvalds
Signed-off-by: Jiri Slaby
---
arch/arc/kernel/unaligned.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/kernel/unaligned.c b/arch/arc/kernel/unaligned.c
index dbde997d16c6..2cc82b6ec23d 100644
--- a/arch/arc/kernel/unaligned.c
+++ b/arch/arc/kernel/unaligned.c
@@ -242,7 +242,7 @@ int misaligned_fixup(unsigned long address, struct pt_regs
*regs,
/* clear any remanants of delay slot */
if (delay_mode(regs)) {
- regs->ret = regs->bta ~1U;
+ regs->ret = regs->bta & ~1U;
regs->status32 &= ~STATUS_DE_MASK;
} else {
regs->ret += state.instr_len;
--
2.12.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check
On Fri, Mar 03, 2017 at 06:05:15PM +, Jose Abreu wrote:
> Hi Alexey,
>
>
> On 03-03-2017 13:27, Alexey Brodkin wrote:
> >
> > So if I understood you correct here what I really need is just to get rid
> > of existing check,
> > right? I.e. the following is to be in v2 respin:
> > --->8---
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index ad9a95916f1f..86f1555914e8 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -129,20 +129,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
> > ~ARCPGU_CTRL_ENABLE_MASK);
> > }
> >
> > -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> > -struct drm_crtc_state *state)
> > -{
> > - struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> > - struct drm_display_mode *mode = &state->adjusted_mode;
> > - long rate, clk_rate = mode->clock * 1000;
> > -
> > - rate = clk_round_rate(arcpgu->clk, clk_rate);
> > - if (rate != clk_rate)
> > - return -EINVAL;
> > -
> > - return 0;
> > -}
> > -
> > static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
> > struct drm_crtc_state *state)
> > {
> > @@ -165,7 +151,6 @@ static const struct drm_crtc_helper_funcs
> > arc_pgu_crtc_helper_funcs = {
> > .disable= arc_pgu_crtc_disable,
> > .prepare= arc_pgu_crtc_disable,
> > .commit = arc_pgu_crtc_enable,
> > - .atomic_check = arc_pgu_crtc_atomic_check,
> > .atomic_begin = arc_pgu_crtc_atomic_begin,
> > };
> > --->8---
>
> I don't think you can remove the check entirely as this will make
> any mode be accepted, right?
Yes there's still the issue of atomic_check/mode_fixup vs. mode_valid. I'm
still trying to volunteer someone to fix up that mess. But at least it's
all properly documented I hope (if not, pls send patch).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check
Hi Alexey, On 03-03-2017 19:24, Alexey Brodkin wrote: > > Correct. Otherwise we'll get some modes and devices that > don't work. > > Remember our saga with 74.25 vs 74.40 MHz? > > With our PLLs on AXS and HSDK boards we may generate 74.25 MHz clock > which satisfy some monitors especially those who pass correct EDID to the > host. > But what if EDID is either corrupted or doesn't exist (that's my case with > some industrial monitor as well as with old DVI monitor)? > > In that case Linux kernel attempts to calculate all the values including > pixel clock > but then instead of 74.25 we'll get 74.40 and equipment that used to work is > no longer useful. > > So strictly speaking existing check makes perfect sense. But it reduces > compatibility with not very good monitors. > > Probably better solution to the problem is just to throw away [my] faulty HW > and > buy equipment that conforms to standards (not really sure if EDID is a hard > requirement for DVI/HDMI displays or this is just an option). Hmm, per DVI and HDMI spec all compliant equipment must support the EDID. So, either you don't have a compliant equipment or the EDID is faulty (maybe wrong checksum), if you activate full debug in drm core you can see the list of probed modes from EDID. Anyway, per spec they must support EDID, otherwise you won't know what modes the display support. I think its not very portable to force a mode because it may not work in some displays. Or, if you want to make sure it is always works choose 640x480@60 because (I think) both DVI and HDMI displays must support this mode (though this would need to change at boot [or at runtime, once AXS PLL driver is in] the clock frequency from 74 to 25Mhz). > > BTW I'm wondering if there're any guidelines on what could be pixel clock > deviation from the requested one? The "flavours" of pixel clock are already handled by drm core (in cea_mode_alternate_clock()) and I think the mode that is passed to the drivers has always the corrected value (i.e. the value may vary when you have 60Hz or 59.94Hz, for example, but only the 60Hz value will be passed to the driver). Best regards, Jose Miguel Abreu > > -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
