Re: radeon_pm.c locking problem

I saw the post; the function affected is this:

static void radeon_pm_program_v2clk(struct radeonfb_info *rinfo)
{
        /* Set v2clk to 65MHz */
        OUTPLL(pllPIXCLKS_CNTL,
                INPLL(pllPIXCLKS_CNTL) & ~PIXCLKS_CNTL__PIX2CLK_SRC_SEL_MASK);

        OUTPLL(pllP2PLL_REF_DIV, 0x0000000c);
        OUTPLL(pllP2PLL_CNTL, 0x0000bf00);
        OUTPLL(pllP2PLL_DIV_0, 0x00020074 | P2PLL_DIV_0__P2PLL_ATOMIC_UPDATE_W);

        OUTPLL(pllP2PLL_CNTL, INPLL(pllP2PLL_CNTL) & ~P2PLL_CNTL__P2PLL_SLEEP);
        mdelay(1);

        OUTPLL(pllP2PLL_CNTL, INPLL(pllP2PLL_CNTL) & ~P2PLL_CNTL__P2PLL_RESET);
        mdelay( 1);

        OUTPLL(pllPIXCLKS_CNTL,
                (INPLL(pllPIXCLKS_CNTL) & ~PIXCLKS_CNTL__PIX2CLK_SRC_SEL_MASK)
                | (0x03 << PIXCLKS_CNTL__PIX2CLK_SRC_SEL__SHIFT));
        mdelay( 1);
}

and the checker program catches the cases where we do something like:

OUTPLL(foo, INPLL(bar) & ~blah);

because both OUTPLL and INPLL grab rinfo->reg_lock.

I think the right solution here - because it's logically one change, no:
Reprogramming the pixel clocks? is to just use the primitive __OUTPLL and
__INPLL and do the locking ourselves around the whole sequence.

-dte


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com