* Re: Radeon fb issue: invalid framebuffer id kernel 3.2.12
From: Fabio Coatti @ 2012-03-21 23:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CADpTngU6fL3r3cHsH3B6Hx68Bm4R_baoBeVmvGf6bUJPV3CXbA@mail.gmail.com>
2012/3/19 Dave Airlie <airlied@gmail.com>:
>> Hi all,
>> I'm setting up a new laptot with Advanced Micro Devices [AMD] nee ATI
>> Seymour [Radeon HD 6400M Series] card, using radeon drivers. I'm
>> facing an issue for wich I found a lot of references but no actual
>> solution, so I'm asking here for some help
>
> the invalid framebuffer id isn't fatal, however it sounds like you
> haven't got CONFIG_FRAMEBUFFER_CONSOLE
> or haven't loaded fbcon.
Indeed your'e right. I was confused by the error and i didn't looked
in the right and obvious place, silly me.
Thanks for the heads up!
--
Fabio
^ permalink raw reply
* [PATCH] kyrofb: fix on x86_64
From: Ondrej Zary @ 2012-03-21 22:36 UTC (permalink / raw)
To: Paul Mundt
Cc: Florian Tobias Schandinat, linux-fbdev, Kernel development list
kyrofb is completely broken on x86_64 because the registers are defined as
unsigned long. Change them to u32 to make the driver work.
Tested with Hercules 3D Prophet 4000XT.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
diff --git a/drivers/video/kyro/STG4000Reg.h b/drivers/video/kyro/STG4000Reg.h
index 5d62698..50f4670 100644
--- a/drivers/video/kyro/STG4000Reg.h
+++ b/drivers/video/kyro/STG4000Reg.h
@@ -73,210 +73,210 @@ typedef enum _OVRL_PIX_FORMAT {
/* Register Table */
typedef struct {
/* 0h */
- volatile unsigned long Thread0Enable; /* 0x0000 */
- volatile unsigned long Thread1Enable; /* 0x0004 */
- volatile unsigned long Thread0Recover; /* 0x0008 */
- volatile unsigned long Thread1Recover; /* 0x000C */
- volatile unsigned long Thread0Step; /* 0x0010 */
- volatile unsigned long Thread1Step; /* 0x0014 */
- volatile unsigned long VideoInStatus; /* 0x0018 */
- volatile unsigned long Core2InSignStart; /* 0x001C */
- volatile unsigned long Core1ResetVector; /* 0x0020 */
- volatile unsigned long Core1ROMOffset; /* 0x0024 */
- volatile unsigned long Core1ArbiterPriority; /* 0x0028 */
- volatile unsigned long VideoInControl; /* 0x002C */
- volatile unsigned long VideoInReg0CtrlA; /* 0x0030 */
- volatile unsigned long VideoInReg0CtrlB; /* 0x0034 */
- volatile unsigned long VideoInReg1CtrlA; /* 0x0038 */
- volatile unsigned long VideoInReg1CtrlB; /* 0x003C */
- volatile unsigned long Thread0Kicker; /* 0x0040 */
- volatile unsigned long Core2InputSign; /* 0x0044 */
- volatile unsigned long Thread0ProgCtr; /* 0x0048 */
- volatile unsigned long Thread1ProgCtr; /* 0x004C */
- volatile unsigned long Thread1Kicker; /* 0x0050 */
- volatile unsigned long GPRegister1; /* 0x0054 */
- volatile unsigned long GPRegister2; /* 0x0058 */
- volatile unsigned long GPRegister3; /* 0x005C */
- volatile unsigned long GPRegister4; /* 0x0060 */
- volatile unsigned long SerialIntA; /* 0x0064 */
-
- volatile unsigned long Fill0[6]; /* GAP 0x0068 - 0x007C */
-
- volatile unsigned long SoftwareReset; /* 0x0080 */
- volatile unsigned long SerialIntB; /* 0x0084 */
-
- volatile unsigned long Fill1[37]; /* GAP 0x0088 - 0x011C */
-
- volatile unsigned long ROMELQV; /* 0x011C */
- volatile unsigned long WLWH; /* 0x0120 */
- volatile unsigned long ROMELWL; /* 0x0124 */
-
- volatile unsigned long dwFill_1; /* GAP 0x0128 */
-
- volatile unsigned long IntStatus; /* 0x012C */
- volatile unsigned long IntMask; /* 0x0130 */
- volatile unsigned long IntClear; /* 0x0134 */
-
- volatile unsigned long Fill2[6]; /* GAP 0x0138 - 0x014C */
-
- volatile unsigned long ROMGPIOA; /* 0x0150 */
- volatile unsigned long ROMGPIOB; /* 0x0154 */
- volatile unsigned long ROMGPIOC; /* 0x0158 */
- volatile unsigned long ROMGPIOD; /* 0x015C */
-
- volatile unsigned long Fill3[2]; /* GAP 0x0160 - 0x0168 */
-
- volatile unsigned long AGPIntID; /* 0x0168 */
- volatile unsigned long AGPIntClassCode; /* 0x016C */
- volatile unsigned long AGPIntBIST; /* 0x0170 */
- volatile unsigned long AGPIntSSID; /* 0x0174 */
- volatile unsigned long AGPIntPMCSR; /* 0x0178 */
- volatile unsigned long VGAFrameBufBase; /* 0x017C */
- volatile unsigned long VGANotify; /* 0x0180 */
- volatile unsigned long DACPLLMode; /* 0x0184 */
- volatile unsigned long Core1VideoClockDiv; /* 0x0188 */
- volatile unsigned long AGPIntStat; /* 0x018C */
+ volatile u32 Thread0Enable; /* 0x0000 */
+ volatile u32 Thread1Enable; /* 0x0004 */
+ volatile u32 Thread0Recover; /* 0x0008 */
+ volatile u32 Thread1Recover; /* 0x000C */
+ volatile u32 Thread0Step; /* 0x0010 */
+ volatile u32 Thread1Step; /* 0x0014 */
+ volatile u32 VideoInStatus; /* 0x0018 */
+ volatile u32 Core2InSignStart; /* 0x001C */
+ volatile u32 Core1ResetVector; /* 0x0020 */
+ volatile u32 Core1ROMOffset; /* 0x0024 */
+ volatile u32 Core1ArbiterPriority; /* 0x0028 */
+ volatile u32 VideoInControl; /* 0x002C */
+ volatile u32 VideoInReg0CtrlA; /* 0x0030 */
+ volatile u32 VideoInReg0CtrlB; /* 0x0034 */
+ volatile u32 VideoInReg1CtrlA; /* 0x0038 */
+ volatile u32 VideoInReg1CtrlB; /* 0x003C */
+ volatile u32 Thread0Kicker; /* 0x0040 */
+ volatile u32 Core2InputSign; /* 0x0044 */
+ volatile u32 Thread0ProgCtr; /* 0x0048 */
+ volatile u32 Thread1ProgCtr; /* 0x004C */
+ volatile u32 Thread1Kicker; /* 0x0050 */
+ volatile u32 GPRegister1; /* 0x0054 */
+ volatile u32 GPRegister2; /* 0x0058 */
+ volatile u32 GPRegister3; /* 0x005C */
+ volatile u32 GPRegister4; /* 0x0060 */
+ volatile u32 SerialIntA; /* 0x0064 */
+
+ volatile u32 Fill0[6]; /* GAP 0x0068 - 0x007C */
+
+ volatile u32 SoftwareReset; /* 0x0080 */
+ volatile u32 SerialIntB; /* 0x0084 */
+
+ volatile u32 Fill1[37]; /* GAP 0x0088 - 0x011C */
+
+ volatile u32 ROMELQV; /* 0x011C */
+ volatile u32 WLWH; /* 0x0120 */
+ volatile u32 ROMELWL; /* 0x0124 */
+
+ volatile u32 dwFill_1; /* GAP 0x0128 */
+
+ volatile u32 IntStatus; /* 0x012C */
+ volatile u32 IntMask; /* 0x0130 */
+ volatile u32 IntClear; /* 0x0134 */
+
+ volatile u32 Fill2[6]; /* GAP 0x0138 - 0x014C */
+
+ volatile u32 ROMGPIOA; /* 0x0150 */
+ volatile u32 ROMGPIOB; /* 0x0154 */
+ volatile u32 ROMGPIOC; /* 0x0158 */
+ volatile u32 ROMGPIOD; /* 0x015C */
+
+ volatile u32 Fill3[2]; /* GAP 0x0160 - 0x0168 */
+
+ volatile u32 AGPIntID; /* 0x0168 */
+ volatile u32 AGPIntClassCode; /* 0x016C */
+ volatile u32 AGPIntBIST; /* 0x0170 */
+ volatile u32 AGPIntSSID; /* 0x0174 */
+ volatile u32 AGPIntPMCSR; /* 0x0178 */
+ volatile u32 VGAFrameBufBase; /* 0x017C */
+ volatile u32 VGANotify; /* 0x0180 */
+ volatile u32 DACPLLMode; /* 0x0184 */
+ volatile u32 Core1VideoClockDiv; /* 0x0188 */
+ volatile u32 AGPIntStat; /* 0x018C */
/*
- volatile unsigned long Fill4[0x0400/4 - 0x0190/4]; //GAP 0x0190 - 0x0400
- volatile unsigned long Fill5[0x05FC/4 - 0x0400/4]; //GAP 0x0400 - 0x05FC Fog Table
- volatile unsigned long Fill6[0x0604/4 - 0x0600/4]; //GAP 0x0600 - 0x0604
- volatile unsigned long Fill7[0x0680/4 - 0x0608/4]; //GAP 0x0608 - 0x0680
- volatile unsigned long Fill8[0x07FC/4 - 0x0684/4]; //GAP 0x0684 - 0x07FC
+ volatile u32 Fill4[0x0400/4 - 0x0190/4]; //GAP 0x0190 - 0x0400
+ volatile u32 Fill5[0x05FC/4 - 0x0400/4]; //GAP 0x0400 - 0x05FC Fog Table
+ volatile u32 Fill6[0x0604/4 - 0x0600/4]; //GAP 0x0600 - 0x0604
+ volatile u32 Fill7[0x0680/4 - 0x0608/4]; //GAP 0x0608 - 0x0680
+ volatile u32 Fill8[0x07FC/4 - 0x0684/4]; //GAP 0x0684 - 0x07FC
*/
- volatile unsigned long Fill4[412]; /* 0x0190 - 0x07FC */
-
- volatile unsigned long TACtrlStreamBase; /* 0x0800 */
- volatile unsigned long TAObjDataBase; /* 0x0804 */
- volatile unsigned long TAPtrDataBase; /* 0x0808 */
- volatile unsigned long TARegionDataBase; /* 0x080C */
- volatile unsigned long TATailPtrBase; /* 0x0810 */
- volatile unsigned long TAPtrRegionSize; /* 0x0814 */
- volatile unsigned long TAConfiguration; /* 0x0818 */
- volatile unsigned long TAObjDataStartAddr; /* 0x081C */
- volatile unsigned long TAObjDataEndAddr; /* 0x0820 */
- volatile unsigned long TAXScreenClip; /* 0x0824 */
- volatile unsigned long TAYScreenClip; /* 0x0828 */
- volatile unsigned long TARHWClamp; /* 0x082C */
- volatile unsigned long TARHWCompare; /* 0x0830 */
- volatile unsigned long TAStart; /* 0x0834 */
- volatile unsigned long TAObjReStart; /* 0x0838 */
- volatile unsigned long TAPtrReStart; /* 0x083C */
- volatile unsigned long TAStatus1; /* 0x0840 */
- volatile unsigned long TAStatus2; /* 0x0844 */
- volatile unsigned long TAIntStatus; /* 0x0848 */
- volatile unsigned long TAIntMask; /* 0x084C */
-
- volatile unsigned long Fill5[235]; /* GAP 0x0850 - 0x0BF8 */
-
- volatile unsigned long TextureAddrThresh; /* 0x0BFC */
- volatile unsigned long Core1Translation; /* 0x0C00 */
- volatile unsigned long TextureAddrReMap; /* 0x0C04 */
- volatile unsigned long RenderOutAGPRemap; /* 0x0C08 */
- volatile unsigned long _3DRegionReadTrans; /* 0x0C0C */
- volatile unsigned long _3DPtrReadTrans; /* 0x0C10 */
- volatile unsigned long _3DParamReadTrans; /* 0x0C14 */
- volatile unsigned long _3DRegionReadThresh; /* 0x0C18 */
- volatile unsigned long _3DPtrReadThresh; /* 0x0C1C */
- volatile unsigned long _3DParamReadThresh; /* 0x0C20 */
- volatile unsigned long _3DRegionReadAGPRemap; /* 0x0C24 */
- volatile unsigned long _3DPtrReadAGPRemap; /* 0x0C28 */
- volatile unsigned long _3DParamReadAGPRemap; /* 0x0C2C */
- volatile unsigned long ZBufferAGPRemap; /* 0x0C30 */
- volatile unsigned long TAIndexAGPRemap; /* 0x0C34 */
- volatile unsigned long TAVertexAGPRemap; /* 0x0C38 */
- volatile unsigned long TAUVAddrTrans; /* 0x0C3C */
- volatile unsigned long TATailPtrCacheTrans; /* 0x0C40 */
- volatile unsigned long TAParamWriteTrans; /* 0x0C44 */
- volatile unsigned long TAPtrWriteTrans; /* 0x0C48 */
- volatile unsigned long TAParamWriteThresh; /* 0x0C4C */
- volatile unsigned long TAPtrWriteThresh; /* 0x0C50 */
- volatile unsigned long TATailPtrCacheAGPRe; /* 0x0C54 */
- volatile unsigned long TAParamWriteAGPRe; /* 0x0C58 */
- volatile unsigned long TAPtrWriteAGPRe; /* 0x0C5C */
- volatile unsigned long SDRAMArbiterConf; /* 0x0C60 */
- volatile unsigned long SDRAMConf0; /* 0x0C64 */
- volatile unsigned long SDRAMConf1; /* 0x0C68 */
- volatile unsigned long SDRAMConf2; /* 0x0C6C */
- volatile unsigned long SDRAMRefresh; /* 0x0C70 */
- volatile unsigned long SDRAMPowerStat; /* 0x0C74 */
-
- volatile unsigned long Fill6[2]; /* GAP 0x0C78 - 0x0C7C */
-
- volatile unsigned long RAMBistData; /* 0x0C80 */
- volatile unsigned long RAMBistCtrl; /* 0x0C84 */
- volatile unsigned long FIFOBistKey; /* 0x0C88 */
- volatile unsigned long RAMBistResult; /* 0x0C8C */
- volatile unsigned long FIFOBistResult; /* 0x0C90 */
+ volatile u32 Fill4[412]; /* 0x0190 - 0x07FC */
+
+ volatile u32 TACtrlStreamBase; /* 0x0800 */
+ volatile u32 TAObjDataBase; /* 0x0804 */
+ volatile u32 TAPtrDataBase; /* 0x0808 */
+ volatile u32 TARegionDataBase; /* 0x080C */
+ volatile u32 TATailPtrBase; /* 0x0810 */
+ volatile u32 TAPtrRegionSize; /* 0x0814 */
+ volatile u32 TAConfiguration; /* 0x0818 */
+ volatile u32 TAObjDataStartAddr; /* 0x081C */
+ volatile u32 TAObjDataEndAddr; /* 0x0820 */
+ volatile u32 TAXScreenClip; /* 0x0824 */
+ volatile u32 TAYScreenClip; /* 0x0828 */
+ volatile u32 TARHWClamp; /* 0x082C */
+ volatile u32 TARHWCompare; /* 0x0830 */
+ volatile u32 TAStart; /* 0x0834 */
+ volatile u32 TAObjReStart; /* 0x0838 */
+ volatile u32 TAPtrReStart; /* 0x083C */
+ volatile u32 TAStatus1; /* 0x0840 */
+ volatile u32 TAStatus2; /* 0x0844 */
+ volatile u32 TAIntStatus; /* 0x0848 */
+ volatile u32 TAIntMask; /* 0x084C */
+
+ volatile u32 Fill5[235]; /* GAP 0x0850 - 0x0BF8 */
+
+ volatile u32 TextureAddrThresh; /* 0x0BFC */
+ volatile u32 Core1Translation; /* 0x0C00 */
+ volatile u32 TextureAddrReMap; /* 0x0C04 */
+ volatile u32 RenderOutAGPRemap; /* 0x0C08 */
+ volatile u32 _3DRegionReadTrans; /* 0x0C0C */
+ volatile u32 _3DPtrReadTrans; /* 0x0C10 */
+ volatile u32 _3DParamReadTrans; /* 0x0C14 */
+ volatile u32 _3DRegionReadThresh; /* 0x0C18 */
+ volatile u32 _3DPtrReadThresh; /* 0x0C1C */
+ volatile u32 _3DParamReadThresh; /* 0x0C20 */
+ volatile u32 _3DRegionReadAGPRemap; /* 0x0C24 */
+ volatile u32 _3DPtrReadAGPRemap; /* 0x0C28 */
+ volatile u32 _3DParamReadAGPRemap; /* 0x0C2C */
+ volatile u32 ZBufferAGPRemap; /* 0x0C30 */
+ volatile u32 TAIndexAGPRemap; /* 0x0C34 */
+ volatile u32 TAVertexAGPRemap; /* 0x0C38 */
+ volatile u32 TAUVAddrTrans; /* 0x0C3C */
+ volatile u32 TATailPtrCacheTrans; /* 0x0C40 */
+ volatile u32 TAParamWriteTrans; /* 0x0C44 */
+ volatile u32 TAPtrWriteTrans; /* 0x0C48 */
+ volatile u32 TAParamWriteThresh; /* 0x0C4C */
+ volatile u32 TAPtrWriteThresh; /* 0x0C50 */
+ volatile u32 TATailPtrCacheAGPRe; /* 0x0C54 */
+ volatile u32 TAParamWriteAGPRe; /* 0x0C58 */
+ volatile u32 TAPtrWriteAGPRe; /* 0x0C5C */
+ volatile u32 SDRAMArbiterConf; /* 0x0C60 */
+ volatile u32 SDRAMConf0; /* 0x0C64 */
+ volatile u32 SDRAMConf1; /* 0x0C68 */
+ volatile u32 SDRAMConf2; /* 0x0C6C */
+ volatile u32 SDRAMRefresh; /* 0x0C70 */
+ volatile u32 SDRAMPowerStat; /* 0x0C74 */
+
+ volatile u32 Fill6[2]; /* GAP 0x0C78 - 0x0C7C */
+
+ volatile u32 RAMBistData; /* 0x0C80 */
+ volatile u32 RAMBistCtrl; /* 0x0C84 */
+ volatile u32 FIFOBistKey; /* 0x0C88 */
+ volatile u32 RAMBistResult; /* 0x0C8C */
+ volatile u32 FIFOBistResult; /* 0x0C90 */
/*
- volatile unsigned long Fill11[0x0CBC/4 - 0x0C94/4]; //GAP 0x0C94 - 0x0CBC
- volatile unsigned long Fill12[0x0CD0/4 - 0x0CC0/4]; //GAP 0x0CC0 - 0x0CD0 3DRegisters
+ volatile u32 Fill11[0x0CBC/4 - 0x0C94/4]; //GAP 0x0C94 - 0x0CBC
+ volatile u32 Fill12[0x0CD0/4 - 0x0CC0/4]; //GAP 0x0CC0 - 0x0CD0 3DRegisters
*/
- volatile unsigned long Fill7[16]; /* 0x0c94 - 0x0cd0 */
+ volatile u32 Fill7[16]; /* 0x0c94 - 0x0cd0 */
- volatile unsigned long SDRAMAddrSign; /* 0x0CD4 */
- volatile unsigned long SDRAMDataSign; /* 0x0CD8 */
- volatile unsigned long SDRAMSignConf; /* 0x0CDC */
+ volatile u32 SDRAMAddrSign; /* 0x0CD4 */
+ volatile u32 SDRAMDataSign; /* 0x0CD8 */
+ volatile u32 SDRAMSignConf; /* 0x0CDC */
/* DWFILL; //GAP 0x0CE0 */
- volatile unsigned long dwFill_2;
-
- volatile unsigned long ISPSignature; /* 0x0CE4 */
-
- volatile unsigned long Fill8[454]; /*GAP 0x0CE8 - 0x13FC */
-
- volatile unsigned long DACPrimAddress; /* 0x1400 */
- volatile unsigned long DACPrimSize; /* 0x1404 */
- volatile unsigned long DACCursorAddr; /* 0x1408 */
- volatile unsigned long DACCursorCtrl; /* 0x140C */
- volatile unsigned long DACOverlayAddr; /* 0x1410 */
- volatile unsigned long DACOverlayUAddr; /* 0x1414 */
- volatile unsigned long DACOverlayVAddr; /* 0x1418 */
- volatile unsigned long DACOverlaySize; /* 0x141C */
- volatile unsigned long DACOverlayVtDec; /* 0x1420 */
-
- volatile unsigned long Fill9[9]; /* GAP 0x1424 - 0x1444 */
-
- volatile unsigned long DACVerticalScal; /* 0x1448 */
- volatile unsigned long DACPixelFormat; /* 0x144C */
- volatile unsigned long DACHorizontalScal; /* 0x1450 */
- volatile unsigned long DACVidWinStart; /* 0x1454 */
- volatile unsigned long DACVidWinEnd; /* 0x1458 */
- volatile unsigned long DACBlendCtrl; /* 0x145C */
- volatile unsigned long DACHorTim1; /* 0x1460 */
- volatile unsigned long DACHorTim2; /* 0x1464 */
- volatile unsigned long DACHorTim3; /* 0x1468 */
- volatile unsigned long DACVerTim1; /* 0x146C */
- volatile unsigned long DACVerTim2; /* 0x1470 */
- volatile unsigned long DACVerTim3; /* 0x1474 */
- volatile unsigned long DACBorderColor; /* 0x1478 */
- volatile unsigned long DACSyncCtrl; /* 0x147C */
- volatile unsigned long DACStreamCtrl; /* 0x1480 */
- volatile unsigned long DACLUTAddress; /* 0x1484 */
- volatile unsigned long DACLUTData; /* 0x1488 */
- volatile unsigned long DACBurstCtrl; /* 0x148C */
- volatile unsigned long DACCrcTrigger; /* 0x1490 */
- volatile unsigned long DACCrcDone; /* 0x1494 */
- volatile unsigned long DACCrcResult1; /* 0x1498 */
- volatile unsigned long DACCrcResult2; /* 0x149C */
- volatile unsigned long DACLinecount; /* 0x14A0 */
-
- volatile unsigned long Fill10[151]; /*GAP 0x14A4 - 0x16FC */
-
- volatile unsigned long DigVidPortCtrl; /* 0x1700 */
- volatile unsigned long DigVidPortStat; /* 0x1704 */
+ volatile u32 dwFill_2;
+
+ volatile u32 ISPSignature; /* 0x0CE4 */
+
+ volatile u32 Fill8[454]; /*GAP 0x0CE8 - 0x13FC */
+
+ volatile u32 DACPrimAddress; /* 0x1400 */
+ volatile u32 DACPrimSize; /* 0x1404 */
+ volatile u32 DACCursorAddr; /* 0x1408 */
+ volatile u32 DACCursorCtrl; /* 0x140C */
+ volatile u32 DACOverlayAddr; /* 0x1410 */
+ volatile u32 DACOverlayUAddr; /* 0x1414 */
+ volatile u32 DACOverlayVAddr; /* 0x1418 */
+ volatile u32 DACOverlaySize; /* 0x141C */
+ volatile u32 DACOverlayVtDec; /* 0x1420 */
+
+ volatile u32 Fill9[9]; /* GAP 0x1424 - 0x1444 */
+
+ volatile u32 DACVerticalScal; /* 0x1448 */
+ volatile u32 DACPixelFormat; /* 0x144C */
+ volatile u32 DACHorizontalScal; /* 0x1450 */
+ volatile u32 DACVidWinStart; /* 0x1454 */
+ volatile u32 DACVidWinEnd; /* 0x1458 */
+ volatile u32 DACBlendCtrl; /* 0x145C */
+ volatile u32 DACHorTim1; /* 0x1460 */
+ volatile u32 DACHorTim2; /* 0x1464 */
+ volatile u32 DACHorTim3; /* 0x1468 */
+ volatile u32 DACVerTim1; /* 0x146C */
+ volatile u32 DACVerTim2; /* 0x1470 */
+ volatile u32 DACVerTim3; /* 0x1474 */
+ volatile u32 DACBorderColor; /* 0x1478 */
+ volatile u32 DACSyncCtrl; /* 0x147C */
+ volatile u32 DACStreamCtrl; /* 0x1480 */
+ volatile u32 DACLUTAddress; /* 0x1484 */
+ volatile u32 DACLUTData; /* 0x1488 */
+ volatile u32 DACBurstCtrl; /* 0x148C */
+ volatile u32 DACCrcTrigger; /* 0x1490 */
+ volatile u32 DACCrcDone; /* 0x1494 */
+ volatile u32 DACCrcResult1; /* 0x1498 */
+ volatile u32 DACCrcResult2; /* 0x149C */
+ volatile u32 DACLinecount; /* 0x14A0 */
+
+ volatile u32 Fill10[151]; /*GAP 0x14A4 - 0x16FC */
+
+ volatile u32 DigVidPortCtrl; /* 0x1700 */
+ volatile u32 DigVidPortStat; /* 0x1704 */
/*
- volatile unsigned long Fill11[0x1FFC/4 - 0x1708/4]; //GAP 0x1708 - 0x1FFC
- volatile unsigned long Fill17[0x3000/4 - 0x2FFC/4]; //GAP 0x2000 - 0x2FFC ALUT
+ volatile u32 Fill11[0x1FFC/4 - 0x1708/4]; //GAP 0x1708 - 0x1FFC
+ volatile u32 Fill17[0x3000/4 - 0x2FFC/4]; //GAP 0x2000 - 0x2FFC ALUT
*/
- volatile unsigned long Fill11[1598];
+ volatile u32 Fill11[1598];
/* DWFILL; //GAP 0x3000 ALUT 256MB offset */
- volatile unsigned long Fill_3;
+ volatile u32 Fill_3;
} STG4000REG;
--
Ondrej Zary
^ permalink raw reply related
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-03-21 20:49 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, Dmitry Eremin-Solenikov, Tony Breeds, linuxppc-dev
In-Reply-To: <4F6A2FEC.6040003@gmx.de>
On Wed, 2012-03-21 at 19:45 +0000, Florian Tobias Schandinat wrote:
> I finally found where we started to discuss this issue, for reference
> "sm501fb.c: support mmap on PPC440SPe/PPC440EPx" back in May 2010.
>
> The thing I don't remember is why we consider exporting the physical
> address to userspace desirable (or even necessary). Fixing the generic
> mmap would be trivial without breaking or adding any userspace ABI, I
> think. Just adding those things to fb_info and adjusting fb_mmap
> should
> do the trick, shouldn't it?
For historical reasons, things like X or directfb used it. Modern X
drivers shouldn't any more, but heh...
Cheers,
Ben.
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Florian Tobias Schandinat @ 2012-03-21 19:45 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linux-fbdev, Tony Breeds, linuxppc-dev
In-Reply-To: <CALT56yPjkPQOaXW4Eg8c-S4+a4Omou_YYacqrsCoTAYeXO0XkA@mail.gmail.com>
On 03/19/2012 02:42 PM, Dmitry Eremin-Solenikov wrote:
> On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:
>>> On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
>>> <benh@kernel.crashing.org> wrote:
>>>> In fact, we could make the new structure such that it doesn't break
>>>> userspace compatibility with 64-bit architectures at all, ie, the "new"
>>>> and "compat" ioctl could remain entirely equivalent on 64-bit.
>>>
>>> I remember stuff about compat_ioctl, but I have never used/implemented
>>> that. Are there any details of requirements for the structures being passed?
>>
>> In that specific case, I meant something else. IE. The old ioctl could
>> remain unchanged, and the new ioctl make the same as the old one on
>> 64-bit platforms.
>
> I don't think this kind of magic would be good. I'd just stick to the new
> ioctl.
I finally found where we started to discuss this issue, for reference
"sm501fb.c: support mmap on PPC440SPe/PPC440EPx" back in May 2010.
The thing I don't remember is why we consider exporting the physical
address to userspace desirable (or even necessary). Fixing the generic
mmap would be trivial without breaking or adding any userspace ABI, I
think. Just adding those things to fb_info and adjusting fb_mmap should
do the trick, shouldn't it?
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-21 19:21 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332298845.10557.343.camel@linux-s257.site>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 5788 bytes --]
On Wed, 2012-03-21 at 11:00 +0800, joeyli wrote:
> æ–¼ 三，2012-03-21 æ–¼ 00:25 +0530，Pradeep Subrahmanion æ到：
> > > >From 5da43d2ee6c87dcf17fda34f0b50fe11b04a16bf Mon Sep 17 00:00:00 2001
> > > From: "Lee, Chun-Yi" <jlee@suse.com>
> > > Date: Tue, 20 Mar 2012 19:00:58 +0800
> > > Subject: [PATCH] acer-wmi: add quirk table for video backlight vendor mode
> > >
> > > There have some acer laptop have broken _BCM implemenation, the AML
> > > code wrote value to EC register but firmware didn't change brighenss.
> > >
> > > Fortunately, the brightness control works on those machines with
> > > vendor mode. So, add quirk table for video backlight vendor mode
> > > and unregister acpi video interface on those machines.
> > >
> > > Tested on Acer TravelMate 4750
> > >
> > > Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> > > ---
> > > drivers/platform/x86/Kconfig | 4 ++++
> > > drivers/platform/x86/acer-wmi.c | 38 +++++++++++++++++++++++++++++++++++---
> > > 2 files changed, 39 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > > index 15dbd8c..fe3a494 100644
> > > --- a/drivers/platform/x86/Kconfig
> > > +++ b/drivers/platform/x86/Kconfig
> > > @@ -26,6 +26,10 @@ config ACER_WMI
> > > depends on RFKILL || RFKILL = n
> > > depends on ACPI_WMI
> > > select INPUT_SPARSEKMAP
> > > + # Acer WMI depends on ACPI_VIDEO when ACPI is enabled
> > > + # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> > > + select VIDEO_OUTPUT_CONTROL if ACPI
> > > + select ACPI_VIDEO if ACPI
> > > ---help---
> > > This is a driver for newer Acer (and Wistron) laptops. It adds
> > > wireless radio and bluetooth control, and on some laptops,
> > > diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> > > index 1e5290b..984a7b5 100644
> > > --- a/drivers/platform/x86/acer-wmi.c
> > > +++ b/drivers/platform/x86/acer-wmi.c
> > > @@ -43,6 +43,7 @@
> > > #include <linux/input/sparse-keymap.h>
> > >
> > > #include <acpi/acpi_drivers.h>
> > > +#include <acpi/video.h>
> > >
> > > MODULE_AUTHOR("Carlos Corbacho");
> > > MODULE_DESCRIPTION("Acer Laptop WMI Extras Driver");
> > > @@ -478,6 +479,33 @@ static struct dmi_system_id acer_quirks[] = {
> > > {}
> > > };
> > >
> > > +static int video_set_backlight_video_vendor(const struct dmi_system_id *d)
> > > +{
> > > + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > > + pr_info("Brightness must be controlled by generic video driver\n");
> > > + return 0;
> > > +}
> > > +
> > > +static const struct dmi_system_id video_vendor_dmi_table[] = {
> > > + {
> > > + .callback = video_set_backlight_video_vendor,
> > > + .ident = "Acer Aspire 4736",
> > > + .matches = {
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4736"),
> > > + },
> > > + },
> > > + {
> > > + .callback = video_set_backlight_video_vendor,
> > > + .ident = "Acer TravelMate 4750",
> > > + .matches = {
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
> > > + },
> > > + },
> > > + {}
> > > +};
> > > +
> > > /* Find which quirks are needed for a particular vendor/ model pair */
> > > static void find_quirks(void)
> > > {
> > > @@ -1981,9 +2009,13 @@ static int __init acer_wmi_init(void)
> > > set_quirks();
> > >
> > > if (acpi_video_backlight_support()) {
> > > - interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > > - pr_info("Brightness must be controlled by "
> > > - "generic video driver\n");
> > > + if (dmi_check_system(video_vendor_dmi_table)) {
> > > + acpi_video_unregister();
> > > + } else {
> > > + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > > + pr_info("Brightness must be controlled by "
> > > + "acpi video driver\n");
> > > + }
> > > }
> > >
> > > if (wmi_has_guid(WMID_GUID3)) {
> >
> > I tried out applied your patch . Boot message shows ,
> >
> > [11.220410] acer_wmi: Brightness must be controlled by generic video
> > driver
> >
> > Now 'acpi_video0' and 'intel_backlight' are present
> > inside /sys/class/backlight .Hot key works like earlier ( ie problem
> > after maximum level still exists).
> > I tried following commands ,
> >
>
> It's not the expected behavior.
>
> This new patch should remove acpi_video0 interface on your machine.
> Please kindly provide your dmidecode:
> dmidecode > dmidecode.log
>
> And,
> please make should the patch really applied, you can do a bit change on
> pr_info message by yourself.
Sorry . I think there was some mistake . I tried the patch again. Now
I see only intel_backlight inside /sys/class/backlight. There is no
acer-wmi interface . Is this the expected behavior ? . Or am I missing
anything ?
>
> > echo 5 > /sys/class/backlight/acpi_video0/brightness
> > echo 5 > /sys/class/backlight/intel_backlight/brightness
> >
> > But it doesn't make any change .
> >
> > In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
> >
> > already starts working with 'acpi_osi=Linux' option.
> >
> > cat /proc/cmdline gives ,
> >
> > BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> > root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
> >
> >
> > Thanks ,
> >
> > Pradeep Subrahmanion
> >
>
> OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
> think the hotkey of backlight control only works with acpi_osi=Linux ?
>
>
> Thanks a lot!
> Joey Lee
>
>
Thanks ,
Pradeep Subrahmanion
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.4
From: Florian Tobias Schandinat @ 2012-03-21 18:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Arnd Bergmann, linux-omap, linux-fbdev
In-Reply-To: <1332333553.2236.8.camel@deskari>
On 03/21/2012 12:39 PM, Tomi Valkeinen wrote:
> From 849c07b1fd3d9f23e8ed94436b6221f8652462c0 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Mon, 19 Mar 2012 15:05:02 +0200
> Subject: [PATCH] OMAPDSS: register dss drivers in module init
>
> We do the dss driver registration in a rather strange way: we have the
> higher level omapdss driver, and we use that driver's probe function to
> register the drivers for the rest of the dss devices.
>
> There doesn't seem to be any reason for that, and additionally the
> soon-to-be-merged patch "ARM: OMAP: omap_device: remove
> omap_device_parent" will break omapdss initialization with the current
> registration model.
>
> This patch changes the registration for all drivers to happen at the
> same place, in the init of the module.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/omap2/dss/core.c | 135 +++++++++++++++++++++++-----------------
> 1 files changed, 77 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 8613f86..e8a1207 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -183,42 +183,6 @@ static int omap_dss_probe(struct platform_device *pdev)
> dss_init_overlay_managers(pdev);
> dss_init_overlays(pdev);
>
> - r = dss_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize DSS platform driver\n");
> - goto err_dss;
> - }
> -
> - r = dispc_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize dispc platform driver\n");
> - goto err_dispc;
> - }
> -
> - r = rfbi_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize rfbi platform driver\n");
> - goto err_rfbi;
> - }
> -
> - r = venc_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize venc platform driver\n");
> - goto err_venc;
> - }
> -
> - r = dsi_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize DSI platform driver\n");
> - goto err_dsi;
> - }
> -
> - r = hdmi_init_platform_driver();
> - if (r) {
> - DSSERR("Failed to initialize hdmi\n");
> - goto err_hdmi;
> - }
> -
> r = dss_initialize_debugfs();
> if (r)
> goto err_debugfs;
> @@ -246,18 +210,6 @@ static int omap_dss_probe(struct platform_device *pdev)
> err_register:
> dss_uninitialize_debugfs();
> err_debugfs:
> - hdmi_uninit_platform_driver();
> -err_hdmi:
> - dsi_uninit_platform_driver();
> -err_dsi:
> - venc_uninit_platform_driver();
> -err_venc:
> - dispc_uninit_platform_driver();
> -err_dispc:
> - rfbi_uninit_platform_driver();
> -err_rfbi:
> - dss_uninit_platform_driver();
> -err_dss:
>
> return r;
> }
> @@ -269,13 +221,6 @@ static int omap_dss_remove(struct platform_device *pdev)
>
> dss_uninitialize_debugfs();
>
> - hdmi_uninit_platform_driver();
> - dsi_uninit_platform_driver();
> - venc_uninit_platform_driver();
> - rfbi_uninit_platform_driver();
> - dispc_uninit_platform_driver();
> - dss_uninit_platform_driver();
> -
> dss_uninit_overlays(pdev);
> dss_uninit_overlay_managers(pdev);
>
> @@ -525,6 +470,80 @@ static int omap_dss_bus_register(void)
>
> /* INIT */
>
> +static int __init omap_dss_register_drivers(void)
> +{
> + int r;
> +
> + r = platform_driver_register(&omap_dss_driver);
> + if (r)
> + return r;
> +
> + r = dss_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize DSS platform driver\n");
> + goto err_dss;
> + }
> +
> + r = dispc_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize dispc platform driver\n");
> + goto err_dispc;
> + }
> +
> + r = rfbi_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize rfbi platform driver\n");
> + goto err_rfbi;
> + }
> +
> + r = venc_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize venc platform driver\n");
> + goto err_venc;
> + }
> +
> + r = dsi_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize DSI platform driver\n");
> + goto err_dsi;
> + }
> +
> + r = hdmi_init_platform_driver();
> + if (r) {
> + DSSERR("Failed to initialize hdmi\n");
> + goto err_hdmi;
> + }
> +
> + return 0;
> +
> +err_hdmi:
> + dsi_uninit_platform_driver();
> +err_dsi:
> + venc_uninit_platform_driver();
> +err_venc:
> + rfbi_uninit_platform_driver();
> +err_rfbi:
> + dispc_uninit_platform_driver();
> +err_dispc:
> + dss_uninit_platform_driver();
> +err_dss:
> + platform_driver_unregister(&omap_dss_driver);
> +
> + return r;
> +}
> +
> +static void __exit omap_dss_unregister_drivers(void)
> +{
> + hdmi_uninit_platform_driver();
> + dsi_uninit_platform_driver();
> + venc_uninit_platform_driver();
> + rfbi_uninit_platform_driver();
> + dispc_uninit_platform_driver();
> + dss_uninit_platform_driver();
> +
> + platform_driver_unregister(&omap_dss_driver);
> +}
> +
> #ifdef CONFIG_OMAP2_DSS_MODULE
> static void omap_dss_bus_unregister(void)
> {
> @@ -541,7 +560,7 @@ static int __init omap_dss_init(void)
> if (r)
> return r;
>
> - r = platform_driver_register(&omap_dss_driver);
> + r = omap_dss_register_drivers();
> if (r) {
> omap_dss_bus_unregister();
> return r;
> @@ -562,7 +581,7 @@ static void __exit omap_dss_exit(void)
> core.vdds_sdi_reg = NULL;
> }
>
> - platform_driver_unregister(&omap_dss_driver);
> + omap_dss_unregister_drivers();
>
> omap_dss_bus_unregister();
> }
> @@ -577,7 +596,7 @@ static int __init omap_dss_init(void)
>
> static int __init omap_dss_init2(void)
> {
> - return platform_driver_register(&omap_dss_driver);
> + return omap_dss_register_drivers();
> }
>
> core_initcall(omap_dss_init);
^ permalink raw reply
* Re: [PATCH v2] fbdev: sh_mipi_dsi: add extra phyctrl for sh_mipi_dsi_info
From: Florian Tobias Schandinat @ 2012-03-21 18:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87mx7awxdd.wl%kuninori.morimoto.gx@renesas.com>
On 03/21/2012 01:34 AM, Kuninori Morimoto wrote:
> sh_mipi uses some clocks, but the method of setup depends on CPU.
>
> Current SuperH (like sh73a0) can control all of these clocks
> by CPG (Clock Pulse Generator).
> It means we can control it by clock framework only.
> But on sh7372, it needs CPG settings AND sh_mipi PHYCTRL::PLLDS,
> and only sh7372 has PHYCTRL::PLLDS.
>
> But on current sh_mipi driver, PHYCTRL::PLLDS of sh7372 was
> overwrote since the callback timing of clock setting was changed
> by c2658b70f06108361aa5024798f9c1bf47c73374
> (fbdev: sh_mipi_dsi: fixup setup timing of sh_mipi_setup()).
> To solve this issue, this patch adds extra .phyctrl.
>
> This patch adds detail explanation for unclear mipi settings
> and fixup wrong PHYCTRL::PLLDS value for ap4evb (0xb -> 0x6).
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> v1 -> v2
>
> - fixup wrong MHz (321 -> 312)
> - Adds explain that this patch fixup wrong PLLDS value for ap4evb
>
> arch/arm/mach-shmobile/board-ap4evb.c | 12 +++++++++---
> drivers/video/sh_mipi_dsi.c | 2 +-
> include/video/sh_mipi_dsi.h | 1 +
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
> index eeb4d96..50fcf1b 100644
> --- a/arch/arm/mach-shmobile/board-ap4evb.c
> +++ b/arch/arm/mach-shmobile/board-ap4evb.c
> @@ -556,20 +556,25 @@ static struct platform_device keysc_device = {
> };
>
> /* MIPI-DSI */
> -#define PHYCTRL 0x0070
> static int sh_mipi_set_dot_clock(struct platform_device *pdev,
> void __iomem *base,
> int enable)
> {
> struct clk *pck = clk_get(&pdev->dev, "dsip_clk");
> - void __iomem *phy = base + PHYCTRL;
>
> if (IS_ERR(pck))
> return PTR_ERR(pck);
>
> if (enable) {
> + /*
> + * DSIPCLK = 24MHz
> + * D-PHY = DSIPCLK * ((0x6*2)+1) = 312MHz (see .phyctrl)
> + * HsByteCLK = D-PHY/8 = 39MHz
> + *
> + * X * Y * FPS > + * (544+72+600+16) * (961+8+8+2) * 30 = 36.1MHz
> + */
> clk_set_rate(pck, clk_round_rate(pck, 24000000));
> - iowrite32(ioread32(phy) | (0xb << 8), phy);
> clk_enable(pck);
> } else {
> clk_disable(pck);
> @@ -598,6 +603,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
> .lcd_chan = &lcdc_info.ch[0],
> .lane = 2,
> .vsynw_offset = 17,
> + .phyctrl = 0x6 << 8,
> .flags = SH_MIPI_DSI_SYNC_PULSES_MODE |
> SH_MIPI_DSI_HSbyteCLK,
> .set_dot_clock = sh_mipi_set_dot_clock,
> diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
> index 05151b8..214482c 100644
> --- a/drivers/video/sh_mipi_dsi.c
> +++ b/drivers/video/sh_mipi_dsi.c
> @@ -271,7 +271,7 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
> iowrite32(0x00000001, base + PHYCTRL);
> udelay(200);
> /* Deassert resets, power on */
> - iowrite32(0x03070001, base + PHYCTRL);
> + iowrite32(0x03070001 | pdata->phyctrl, base + PHYCTRL);
>
> /*
> * Default = ULPS enable |
> diff --git a/include/video/sh_mipi_dsi.h b/include/video/sh_mipi_dsi.h
> index 434d56b..06c67fb 100644
> --- a/include/video/sh_mipi_dsi.h
> +++ b/include/video/sh_mipi_dsi.h
> @@ -51,6 +51,7 @@ struct sh_mipi_dsi_info {
> int lane;
> unsigned long flags;
> u32 clksrc;
> + u32 phyctrl; /* for extra setting */
> unsigned int vsynw_offset;
> int (*set_dot_clock)(struct platform_device *pdev,
> void __iomem *base,
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Florian Tobias Schandinat @ 2012-03-21 18:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
On 03/21/2012 01:27 AM, Kuninori Morimoto wrote:
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> v3 -> v4
>
> - move config to before endpoint
>
> drivers/video/Kconfig | 23 +++++++++++------------
> 1 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 8951cbd..0fb9540 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
> ---help---
> Driver for the on-chip SH-Mobile HDMI controller.
>
> -config FB_SH_MOBILE_MERAM
> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
> - depends on FB_SH_MOBILE_LCDC
> - default y
> - ---help---
> - Enable MERAM support for the SH-Mobile LCD controller.
> -
> - This will allow for caching of the framebuffer to provide more
> - reliable access under heavy main memory bus traffic situations.
> - Up to 4 memory channels can be configured, allowing 4 RGB or
> - 2 YCbCr framebuffers to be configured.
> -
> config FB_TMIO
> tristate "Toshiba Mobile IO FrameBuffer support"
> depends on FB && MFD_CORE
> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
> source "drivers/video/logo/Kconfig"
> endif
>
> +config FB_SH_MOBILE_MERAM
> + tristate "SuperH Mobile MERAM read ahead support"
> + depends on (SUPERH || ARCH_SHMOBILE)
> + ---help---
> + Enable MERAM support for the SuperH controller.
> +
> + This will allow for caching of the framebuffer to provide more
> + reliable access under heavy main memory bus traffic situations.
> + Up to 4 memory channels can be configured, allowing 4 RGB or
> + 2 YCbCr framebuffers to be configured.
> +
> endmenu
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.4
From: Florian Tobias Schandinat @ 2012-03-21 18:45 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Arnd Bergmann, linux-omap, linux-fbdev
In-Reply-To: <1332154865.2144.57.camel@deskari>
On 03/19/2012 11:01 AM, Tomi Valkeinen wrote:
> Hi Florian, Arnd,
>
> Here are the changes for OMAP DSS driver for v3.4.
>
> There's an issue with the dss driver that appears on arm-soc/for-next
> branch, which I'm still solving
> (http://marc.info/?l=linux-omap&m\x133214966902577&w=2). I hope to get
> fix for that ready and merged for -rc1, but I'm not sure if I can make
> it in time, so I wanted to sent this pull request already.
>
> Arnd, as discussed before, you can also merge this branch to solve the
> conflicts between arm-soc and omapdss trees.
>
> Note that this is the first pull request I've sent with a branch that I
> have not been rebasing, so please check that the branch looks sane.
>
> Tomi
>
> The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
>
> Linux 3.3 (2012-03-18 16:15:34 -0700)
Interesting, I never tried to start at a commit that is not part of the
branch. Good to know that it does work.
>
> are available in the git repository at:
> git://gitorious.org/linux-omap-dss2/linux.git for-3.4
Merged.
Thanks,
Florian Tobias Schandinat
>
> Archit Taneja (2):
> OMAPDSS: Features: Maintain dss_feats as a list
> OMAPDSS: DISPC: Fix scaling constraints for OMAP4
>
> Danny Kukawka (1):
> OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4
>
> Grazvydas Ignotas (2):
> OMAPDSS: TPO-TD03MTEA1: fix suspend hang
> OMAPDSS: TPO-TD03MTEA1: update default gamma
>
> Julia Lawall (1):
> OMAPDSS: use devm_ functions
>
> Lajos Molnar (3):
> OMAPDSS: DISPC: Fix OMAP4 supported color formats
> OMAPDSS: DISPC: Fix FIR coefficients
> OMAPDSS: MANAGER/APPLY: Add runtime_pm protection around wait_for_go/vsync functions
>
> Mythri P K (6):
> OMAPDSS: HDMI: remove duplicate video interface code
> OMAPDSS: HDMI: update static timing table
> OMAPDSS: HDMI: change the timing match logic
> OMAPDSS: HDMI: remove duplicate code and mode parameter
> OMAPDSS: HDMI: Move Avi-infoframe struct to hdmi_ip_data
> OMAPDSS: HDMI: Add M2 divider while calculating clkout
>
> Ricardo Neri (4):
> OMAPDSS: HDMI: Correct source of the pixel clock in ACR calculation
> OMAPDSS: Add DSS feature for HDMI MCLK for audio
> OMAPDSS: HDMI: Implement initialization of MCLK
> OMAPDSS: HDMI: Modify logic to configure MCLK
>
> Tomi Valkeinen (29):
> OMAPDSS: FEAT: Add FIFO_MERGE feature
> OMAPDSS: APPLY: add fifo merge support funcs
> OMAPDSS: APPLY: add fifo-merge support
> OMAPDSS: DISPC: print fifo threshold values in bytes
> OMAPDSS: DISPC: move fifo threhold calc to dispc.c
> OMAPDSS: DISPC: Add naive threshold calc for fifomerge
> Merge branch 'work/fifomerge'
> Merge commit 'v3.3-rc4'
> OMAPDSS: cleanup probe functions
> OMAPFB: remove old blizzard driver
> OMAPFB: Remove OMAP2/3 support from old omapfb driver
> OMAPDSS: Remove video SRAM support
> OMAPFB: Remove video SRAM support (old omapfb)
> OMAP2+: remove unneeded #include omapfb.h
> OMAP: N770: remove HWA742 platform data
> OAMPFB: remove unused omapfb_set_ctrl_platform_data()
> OMAPFB: remove early mem alloc from old omapfb
> OMAPFB: remove mem info from platform_data
> OMAPFB: remove unused fb_format_to_dss_mode()
> OMAPFB: Move old omapfb private structs to a private include file
> OMAPFB: remove omapfb_set_platform_data()
> OMAP1: pass LCD config with omapfb_set_lcd_config()
> OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM
> OMAP1: Remove unused LCD devices from board files
> OMAPFB: remove remaining OMAP arch checks
> Merge branch 'work/old-omapfb-removal'
> Merge commit 'v3.3-rc6'
> OMAPDSS: APPLY: print warning if wait_pending_extra_info_updates fails
> OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update
>
> Tony Lindgren (1):
> ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set
>
> Yegor Yefremov (1):
> OMAPDSS: add Innolux AT080TN52 display support
>
> arch/arm/mach-omap1/board-ams-delta.c | 9 +-
> arch/arm/mach-omap1/board-fsample.c | 15 +-
> arch/arm/mach-omap1/board-h2.c | 15 +-
> arch/arm/mach-omap1/board-h3.c | 9 +-
> arch/arm/mach-omap1/board-htcherald.c | 9 +-
> arch/arm/mach-omap1/board-innovator.c | 11 +-
> arch/arm/mach-omap1/board-nokia770.c | 19 +-
> arch/arm/mach-omap1/board-osk.c | 14 +-
> arch/arm/mach-omap1/board-palmte.c | 10 +-
> arch/arm/mach-omap1/board-palmtt.c | 10 +-
> arch/arm/mach-omap1/board-palmz71.c | 10 +-
> arch/arm/mach-omap1/board-perseus2.c | 15 +-
> arch/arm/mach-omap1/board-sx1.c | 16 +-
> arch/arm/mach-omap2/io.c | 1 -
> arch/arm/plat-omap/common.c | 2 -
> arch/arm/plat-omap/fb.c | 334 +----
> arch/arm/plat-omap/fb.h | 10 -
> arch/arm/plat-omap/include/plat/blizzard.h | 12 -
> arch/arm/plat-omap/include/plat/board.h | 2 -
> arch/arm/plat-omap/include/plat/hwa742.h | 8 -
> arch/arm/plat-omap/include/plat/vram.h | 21 +-
> drivers/video/omap/Kconfig | 16 +-
> drivers/video/omap/Makefile | 12 +-
> drivers/video/omap/blizzard.c | 1648 --------------------
> drivers/video/omap/dispc.c | 1547 ------------------
> drivers/video/omap/dispc.h | 46 -
> drivers/video/omap/hwa742.c | 21 +-
> drivers/video/omap/omapfb.h | 25 +-
> drivers/video/omap/omapfb_main.c | 30 +-
> drivers/video/omap/rfbi.c | 598 -------
> drivers/video/omap2/displays/panel-generic-dpi.c | 23 +
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 153 ++-
> drivers/video/omap2/dss/apply.c | 275 +++-
> drivers/video/omap2/dss/dispc.c | 121 +-
> drivers/video/omap2/dss/dispc_coefs.c | 9 +-
> drivers/video/omap2/dss/display.c | 10 -
> drivers/video/omap2/dss/dsi.c | 65 +-
> drivers/video/omap2/dss/dss.c | 17 +-
> drivers/video/omap2/dss/dss.h | 10 +-
> drivers/video/omap2/dss/dss_features.c | 181 ++-
> drivers/video/omap2/dss/dss_features.h | 54 +-
> drivers/video/omap2/dss/hdmi.c | 278 ++--
> drivers/video/omap2/dss/manager.c | 12 +-
> drivers/video/omap2/dss/rfbi.c | 36 +-
> drivers/video/omap2/dss/ti_hdmi.h | 56 +-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 94 +-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 47 -
> drivers/video/omap2/dss/venc.c | 32 +-
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 101 +--
> drivers/video/omap2/vram.c | 99 +--
> include/linux/omapfb.h | 32 +-
> 52 files changed, 1001 insertions(+), 5201 deletions(-)
> delete mode 100644 arch/arm/plat-omap/fb.h
> delete mode 100644 arch/arm/plat-omap/include/plat/blizzard.h
> delete mode 100644 arch/arm/plat-omap/include/plat/hwa742.h
> delete mode 100644 drivers/video/omap/blizzard.c
> delete mode 100644 drivers/video/omap/dispc.c
> delete mode 100644 drivers/video/omap/dispc.h
> delete mode 100644 drivers/video/omap/rfbi.c
>
^ permalink raw reply
* Re: [PATCH] video: pxafb: add clk_prepare/clk_unprepare calls
From: Florian Tobias Schandinat @ 2012-03-21 18:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1331835120.14662.3.camel@flow>
On 03/15/2012 06:12 PM, Philipp Zabel wrote:
> This patch adds clk_prepare/clk_unprepare calls to the pxafb
> driver by using the helper functions clk_prepare_enable and
> clk_disable_unprepare.
>
> Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/pxafb.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
> index 1d1e4f1..904f839 100644
> --- a/drivers/video/pxafb.c
> +++ b/drivers/video/pxafb.c
> @@ -1431,7 +1431,7 @@ static void pxafb_enable_controller(struct pxafb_info *fbi)
> pr_debug("reg_lccr3 0x%08x\n", (unsigned int) fbi->reg_lccr3);
>
> /* enable LCD controller clock */
> - clk_enable(fbi->clk);
> + clk_prepare_enable(fbi->clk);
>
> if (fbi->lccr0 & LCCR0_LCDT)
> return;
> @@ -1471,7 +1471,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
> wait_for_completion_timeout(&fbi->disable_done, 200 * HZ / 1000);
>
> /* disable LCD controller clock */
> - clk_disable(fbi->clk);
> + clk_disable_unprepare(fbi->clk);
> }
>
> /*
^ permalink raw reply
* Re: [PATCH] fbdev: bfin_adv7393fb: Drop needless include
From: Florian Tobias Schandinat @ 2012-03-21 18:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120315101449.65566857@endymion.delvare>
On 03/15/2012 09:14 AM, Jean Delvare wrote:
> Kernel drivers don't need <linux/i2c-dev.h>.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Michael Hennerich <michael.hennerich@analog.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/bfin_adv7393fb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> --- linux-3.3-rc7.orig/drivers/video/bfin_adv7393fb.c 2012-01-06 11:21:14.000000000 +0100
> +++ linux-3.3-rc7/drivers/video/bfin_adv7393fb.c 2012-03-15 10:09:32.345820005 +0100
> @@ -36,9 +36,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/proc_fs.h>
> #include <linux/platform_device.h>
> -
> #include <linux/i2c.h>
> -#include <linux/i2c-dev.h>
>
> #include "bfin_adv7393fb.h"
>
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] fbdev: da8xx:: fix reporting of the display timing info
From: Florian Tobias Schandinat @ 2012-03-21 18:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1331644384-5408-1-git-send-email-agust@denx.de>
Applied both patches of this series.
Thanks,
Florian Tobias Schandinat
On 03/13/2012 01:13 PM, Anatolij Gustschin wrote:
> Timing info is not properly reported by the driver, e.g.:
>
> $ fbset -i
> mode "480x272-35"
> # D: 7.895 MHz, H: 12.165 kHz, V: 35.158 Hz
> geometry 480 272 480 544 16
> timings 126666 64 64 32 32 41 10
>
> According to the timing values defined for LK043T1DG01 display
> it should be reported as:
>
> mode "480x272-53"
> # D: 7.895 MHz, H: 15.038 kHz, V: 52.579 Hz
> geometry 480 272 480 544 16
> timings 126666 2 2 2 2 41 10
>
> Initialize additional fb_var_screeninfo fields so fix this problem.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> v2:
> - removed pixclock setting as it is already done in fbdev-next
> - rebased on fbdev-next branch
>
> drivers/video/da8xx-fb.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index dd80386..8f7e051 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -1231,6 +1231,10 @@ static int __devinit fb_probe(struct platform_device *device)
>
> da8xx_fb_var.hsync_len = lcdc_info->hsw;
> da8xx_fb_var.vsync_len = lcdc_info->vsw;
> + da8xx_fb_var.right_margin = lcdc_info->hfp;
> + da8xx_fb_var.left_margin = lcdc_info->hbp;
> + da8xx_fb_var.lower_margin = lcdc_info->vfp;
> + da8xx_fb_var.upper_margin = lcdc_info->vbp;
> da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
>
> /* Initialize fbinfo */
^ permalink raw reply
* Re: [PULL for v3.4] SH mobile LCDC cleanups and fixes
From: Florian Tobias Schandinat @ 2012-03-21 18:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <2909866.e1WXYoJFDz@avalon>
On 03/12/2012 09:48 PM, Laurent Pinchart wrote:
> Hi Florian,
>
> Here's the next round of SH mobile LCDC and MERAM cleanups and fixes based on
> top of your fbdev-next branch (as of right now). All the patches have been
> posted to the list and I've incorporated acked-by and tested-by lines when
> available.
>
> The following changes since commit c2bc0a756b1f98bd712fabe78eb49d7d5ae72075:
>
> video:uvesafb: notice user when we failed to save hardware state (2012-03-08
> 18:13:10 +0000)
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git for-next
Merged.
Thanks,
Florian Tobias Schandinat
>
> Laurent Pinchart (55):
> fbdev: sh_mobile_lcdc: Reorder code into sections
> fbdev: sh_mobile_lcdc: Mark init-only symbols with __devinit(const)
> fbdev: sh_mobile_lcdc: Move pm runtime enable to probe()
> fbdev: sh_mobile_lcdc: Don't pass struct device around
> fbdev: sh_mobile_lcdc: Create functions to turn the display on/off
> fbdev: sh_mobile_hdmi: Don't access LCDC channel in notifier callback
> sh_mobile_hdmi: Remove platform data lcd_dev field
> fbdev: sh_mobile_lcdc: Add sh_mobile_lcdc_entity definition
> fbdev: sh_mobile_hdmi: Implement sh_mobile_lcdc_entity interface
> fbdev: sh_mipi_dsi: Implement sh_mobile_lcdc_entity interface
> fbdev: sh_mobile_lcdc: Handle HDMI/MIPI transmitter device directly
> arm: mach-shmobile: Add LCDC tx_dev field to platform data
> fbdev: sh_mipi_dsi: Don't hook up into board_cfg display operations
> fbdev: sh_mobile_hdmi: Don't hook up into board_cfg display operations
> arm: mach-shmobile: Don't initialize the hdmi_info lcd_chan field
> fbdev: sh_mobile_hdmi: Remove sh_mobile_hdmi_info lcd_chan field
> fbdev: sh_mobile_lcdc: Remove board configuration owner field
> fbdev: sh_mobile_lcdc: Remove board configuration board_data field
> fbdev: sh_mobile_lcdc: Move brightness ops to sh_mobile_lcdc_bl_info
> fbdev: sh_mobile_lcdc: Merge board_cfg and lcd_size_cfg into panel_cfg
> sh_mobile_lcdc: Add an lcdc channel pointer to sh_mobile_lcdc_entity
> sh_mobile_hdmi: Use sh_mobile_lcdc_entity::channel to access fb_info
> fbdev: sh_mobile_lcdc: Remove fb_info parameter to display_on operation
> fbdev: sh_mobile_lcdc: Return display connection state in display_on
> sh_mobile_lcdc: Add display notify callback to sh_mobile_lcdc_chan
> sh_mobile_hdmi: Use LCDC notification callback
> fbdev: sh_mobile_lcdc: Pass a video mode to the notify callback
> fbdev: sh_mobile_hdmi: Don't set sh_hdmi::mode in the display on handler
> fbdev: sh_mobile_hdmi: Don't access LCDC fb_info
> fbdev: sh_mobile_lcdc: Store display mode in a struct fb_videomode
> fbdev: sh_mobile_lcdc: Rename (lcd|num)_cfg (lcd|num)_modes
> fbdev: sh_mobile_lcdc: Reorganize the sh_mobile_lcdc_chan structure
> fbdev: sh_mobile_lcdc: Add sh_mobile_format_info() function
> fbdev: sh_mobile_lcdc: Store the format in struct sh_mobile_lcdc_chan
> fbdev: sh_mobile_lcdc: Split fb init/cleanup from channel init/cleanup
> fbdev: sh_mobile_lcdc: Pass physical device pointer to DMA functions
> fbdev: sh_mobile_lcdc: Store configuration in channel structure
> fbdev: sh_mobile_lcdc: Pass channel pointer to sh_mobile_wait_for_vsync
> arm: mach-shmobile: Split MERAM resources into regs and meram
> fbdev: sh_mobile_meram: Request memory regions for memory resources
> fbdev: sh_mobile_meram: Add _cfg suffix to struct sh_mobile_meram_icb
> fbdev: sh_mobile_meram: Make variables unsigned where applicable
> fbdev: sh_mobile_meram: Make current_reg field store the current reg set
> fbdev: sh_mobile_meram: Add struct sh_mobile_meram_icb
> fbdev: sh_mobile_meram: Don't inline everything
> fbdev: sh_mobile_meram: Divide the code into sections
> fbdev: sh_mobile_meram: Use genalloc to manage MERAM allocation
> fbdev: sh_mobile_meram: Allocate ICBs automatically
> arm: mach-shmobile: Don't set MERAM ICB numbers in platform data
> fbdev: sh_mobile_meram: Remove unused sh_mobile_meram_icb_cfg fields
> fbdev: sh_mobile_lcdc: Don't store copy of platform data
> arm: mach-shmobile: Constify sh_mobile_meram_cfg structures
> fbdev: sh_mobile_meram: Don't perform update in register operation
> fbdev: sh_mobile_meram: Remove unneeded sanity checks
> fbdev: sh_mobile_meram: Implement system suspend/resume
>
> arch/arm/mach-shmobile/board-ag5evm.c | 24 +-
> arch/arm/mach-shmobile/board-ap4evb.c | 290 +++---
> arch/arm/mach-shmobile/board-bonito.c | 6 +-
> arch/arm/mach-shmobile/board-mackerel.c | 106 +--
> arch/sh/boards/mach-ap325rxa/setup.c | 22 +-
> arch/sh/boards/mach-ecovec24/setup.c | 20 +-
> arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 10 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 8 +-
> arch/sh/boards/mach-migor/lcd_qvga.c | 3 +-
> arch/sh/boards/mach-migor/setup.c | 16 +-
> arch/sh/boards/mach-se/7724/setup.c | 12 +-
> arch/sh/include/mach-kfr2r09/mach/kfr2r09.h | 16 +-
> arch/sh/include/mach-migor/mach/migor.h | 2 +-
> drivers/video/Kconfig | 1 +
> drivers/video/sh_mipi_dsi.c | 97 +--
> drivers/video/sh_mobile_hdmi.c | 297 ++-----
> drivers/video/sh_mobile_lcdcfb.c | 1298 +++++++++++++++-----------
> drivers/video/sh_mobile_lcdcfb.h | 84 ++-
> drivers/video/sh_mobile_meram.c | 690 ++++++++-------
> include/video/sh_mobile_hdmi.h | 2 -
> include/video/sh_mobile_lcdc.h | 35 +-
> include/video/sh_mobile_meram.h | 45 +-
> 22 files changed, 1594 insertions(+), 1490 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/7] drivers/video/pvr2fb.c: ensure arguments to request_irq and free_irq are compatible
From: Florian Tobias Schandinat @ 2012-03-21 18:37 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1331494587-12196-2-git-send-email-Julia.Lawall@lip6.fr>
On 03/11/2012 07:36 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Convert calls to free_irq so that the second argument is the same as the
> last argument of the corresponding call to request_irq. Without this
> property, free_irq does nothing.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> Not tested.
>
> drivers/video/pvr2fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
> index 3a3fdc6..bcd44c3 100644
> --- a/drivers/video/pvr2fb.c
> +++ b/drivers/video/pvr2fb.c
> @@ -895,7 +895,7 @@ static int __init pvr2fb_dc_init(void)
>
> #ifdef CONFIG_PVR2_DMA
> if (request_dma(pvr2dma, "pvr2") != 0) {
> - free_irq(HW_EVENT_VSYNC, 0);
> + free_irq(HW_EVENT_VSYNC, fb_info);
> return -EBUSY;
> }
> #endif
> @@ -914,7 +914,7 @@ static void __exit pvr2fb_dc_exit(void)
> currentpar->mmio_base = 0;
> }
>
> - free_irq(HW_EVENT_VSYNC, 0);
> + free_irq(HW_EVENT_VSYNC, fb_info);
> #ifdef CONFIG_PVR2_DMA
> free_dma(pvr2dma);
> #endif
>
>
^ permalink raw reply
* Re: [PATCH] video:uvesafb: notice user when we failed to save hardware state
From: Florian Tobias Schandinat @ 2012-03-21 18:35 UTC (permalink / raw)
To: Wang YanQing, spock, linux-fbdev, linux-kernel
In-Reply-To: <20120302014531.GA3597@udknight>
On 03/02/2012 01:45 AM, Wang YanQing wrote:
>
> uvesafb_open may failed to save hardware state when kmalloc failed
> in uvesafb_vbe_state_save, we should check this and notice user.
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/uvesafb.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index e7f69ef..9db3de3 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -362,7 +362,7 @@ static u8 *uvesafb_vbe_state_save(struct uvesafb_par *par)
>
> state = kmalloc(par->vbe_state_size, GFP_KERNEL);
> if (!state)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> task = uvesafb_prep();
> if (!task) {
> @@ -1172,9 +1172,17 @@ static int uvesafb_open(struct fb_info *info, int user)
> {
> struct uvesafb_par *par = info->par;
> int cnt = atomic_read(&par->ref_count);
> + u8 *buf = NULL;
>
> - if (!cnt && par->vbe_state_size)
> - par->vbe_state_orig = uvesafb_vbe_state_save(par);
> + if (!cnt && par->vbe_state_size) {
> + buf = uvesafb_vbe_state_save(par);
> + if (IS_ERR(buf)) {
> + printk(KERN_WARNING "uvesafb: save hardware state"
> + "failed, error code is %ld!\n", PTR_ERR(buf));
> + } else {
> + par->vbe_state_orig = buf;
> + }
> + }
>
> atomic_inc(&par->ref_count);
> return 0;
^ permalink raw reply
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Florian Tobias Schandinat @ 2012-03-21 18:34 UTC (permalink / raw)
To: Wang YanQing, linux-fbdev, linux-kernel, spock
In-Reply-To: <20120302004850.GA4139@udknight>
On 03/02/2012 12:48 AM, Wang YanQing wrote:
>
> Ok! I think I have learned to make thing simple and send to the right people:)
> This patch try to fix the oops below that catched in my machine
>
> [ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0
> [ 81.609384] uvesafb: protected mode interface info at c000:d350
> [ 81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
> [ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
> [ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
> [ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
> [ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtualI15
> [ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> [ 81.744153] BUG: unable to handle kernel paging request at c00cd3b3
> [ 81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
> [ 81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
> [ 81.744171] Oops: 0011 [#1] SMP
> [ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
> [ 81.744178]
> [ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741
> [ 81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
> [ 81.744187] EIP is at 0xc00cd3b3
> [ 81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
> [ 81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
> [ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 81.744195] Process modprobe (pid: 3497, tiõ7f2000 task÷48c600 task.tiõ7f2000)
> [ 81.744196] Stack:
> [ 81.744197] f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
> [ 81.744202] f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
> [ 81.744206] f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
> [ 81.744210] Call Trace:
> [ 81.744215] [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
> [ 81.744222] [<c124a9bc>] fb_pan_display+0x10c/0x160
> [ 81.744226] [<f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
> [ 81.744230] [<c12598dd>] bit_update_start+0x1d/0x50
> [ 81.744232] [<c1255efe>] fbcon_switch+0x39e/0x550
> [ 81.744235] [<c125a21a>] ? bit_cursor+0x4ea/0x560
> [ 81.744240] [<c129b6cb>] redraw_screen+0x12b/0x220
> [ 81.744245] [<c128843b>] ? tty_do_resize+0x3b/0xc0
> [ 81.744247] [<c129ef42>] vc_do_resize+0x3d2/0x3e0
> [ 81.744250] [<c129efb4>] vc_resize+0x14/0x20
> [ 81.744253] [<c12586bd>] fbcon_init+0x29d/0x500
> [ 81.744255] [<c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110
> [ 81.744258] [<c129b378>] visual_init+0xb8/0x150
> [ 81.744261] [<c129c16c>] bind_con_driver+0x16c/0x360
> [ 81.744264] [<c129b47e>] ? register_con_driver+0x6e/0x190
> [ 81.744267] [<c129c3a1>] take_over_console+0x41/0x50
> [ 81.744269] [<c1257b7a>] fbcon_takeover+0x6a/0xd0
> [ 81.744272] [<c12594b8>] fbcon_event_notify+0x758/0x790
> [ 81.744277] [<c10929e2>] notifier_call_chain+0x42/0xb0
> [ 81.744280] [<c1092d30>] __blocking_notifier_call_chain+0x60/0x90
> [ 81.744283] [<c1092d7a>] blocking_notifier_call_chain+0x1a/0x20
> [ 81.744285] [<c124a5a1>] fb_notifier_call_chain+0x11/0x20
> [ 81.744288] [<c124b759>] register_framebuffer+0x1d9/0x2b0
> [ 81.744293] [<c1061c73>] ? ioremap_wc+0x33/0x40
> [ 81.744298] [<f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb]
> [ 81.744302] [<c12bb81f>] platform_drv_probe+0xf/0x20
> [ 81.744306] [<c12ba558>] driver_probe_device+0x68/0x170
> [ 81.744309] [<c12ba731>] __device_attach+0x41/0x50
> [ 81.744313] [<c12b9088>] bus_for_each_drv+0x48/0x70
> [ 81.744316] [<c12ba7f3>] device_attach+0x83/0xa0
> [ 81.744319] [<c12ba6f0>] ? __driver_attach+0x90/0x90
> [ 81.744321] [<c12b991f>] bus_probe_device+0x6f/0x90
> [ 81.744324] [<c12b8a45>] device_add+0x5e5/0x680
> [ 81.744329] [<c122a1a3>] ? kvasprintf+0x43/0x60
> [ 81.744332] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744335] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744339] [<c12bbe9f>] platform_device_add+0xff/0x1b0
> [ 81.744343] [<f8252906>] uvesafb_init+0x50/0x9b [uvesafb]
> [ 81.744346] [<c100111f>] do_one_initcall+0x2f/0x170
> [ 81.744350] [<f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
> [ 81.744355] [<c10c6994>] sys_init_module+0xf4/0x1410
> [ 81.744359] [<c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
> [ 81.744363] [<c144cb10>] sysenter_do_call+0x12/0x36
> [ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
> [ 81.744388] EIP: [<c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:f57f3a00
> [ 81.744391] CR2: 00000000c00cd3b3
> [ 81.744393] ---[ end trace 18b2c87c925b54d6 ]---
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
I applied this patch but as there is opposition against exporting
'pcibios_enabled' and otherwise the building uvesafb as a module would
be broken I reverted it for this merge window, sorry. If you get this
solved I'd like to push it in some -rc (as well as in stable).
Best regards,
Florian Tobias Schandinat
> ---
> drivers/video/uvesafb.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index e7f69ef..f9a670d 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -23,6 +23,7 @@
> #include <video/uvesafb.h>
> #ifdef CONFIG_X86
> #include <video/vga.h>
> +#include <linux/pci.h>
> #endif
> #ifdef CONFIG_MTRR
> #include <asm/mtrr.h>
> @@ -815,8 +816,15 @@ static int __devinit uvesafb_vbe_init(struct fb_info *info)
> par->pmi_setpal = pmi_setpal;
> par->ypan = ypan;
>
> - if (par->pmi_setpal || par->ypan)
> - uvesafb_vbe_getpmi(task, par);
> + if (par->pmi_setpal || par->ypan) {
> + if (pcibios_enabled) {
> + uvesafb_vbe_getpmi(task, par);
> + } else {
> + par->pmi_setpal = par->ypan = 0;
> + printk(KERN_WARNING "uvesafb: PCI BIOS area is NX."
> + "Can't use protected mode interface\n");
> + }
> + }
> #else
> /* The protected mode interface is not available on non-x86. */
> par->pmi_setpal = par->ypan = 0;
^ permalink raw reply
* Re: [PATCH v2] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Florian Tobias Schandinat @ 2012-03-21 18:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1330499200-20819-1-git-send-email-olivier@sobrie.be>
On 02/29/2012 07:06 AM, Olivier Sobrie wrote:
> Return a negative errno instead of zero in the write function of
> the sysfs entry in case of error.
> Also add a check on the return value of dlfb_setup_modes().
>
> Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
As Bernie did agree in the pull request, I applied this patch.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/udlfb.c | 19 +++++++++++--------
> 1 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index a197731..bfd2a56 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1427,19 +1427,22 @@ static ssize_t edid_store(
> struct device *fbdev = container_of(kobj, struct device, kobj);
> struct fb_info *fb_info = dev_get_drvdata(fbdev);
> struct dlfb_data *dev = fb_info->par;
> + int ret;
>
> /* We only support write of entire EDID at once, no offset*/
> if ((src_size != EDID_LENGTH) || (src_off != 0))
> - return 0;
> + return -EINVAL;
>
> - dlfb_setup_modes(dev, fb_info, src, src_size);
> + ret = dlfb_setup_modes(dev, fb_info, src, src_size);
> + if (ret)
> + return ret;
>
> - if (dev->edid && (memcmp(src, dev->edid, src_size) = 0)) {
> - pr_info("sysfs written EDID is new default\n");
> - dlfb_ops_set_par(fb_info);
> - return src_size;
> - } else
> - return 0;
> + if (!dev->edid || memcmp(src, dev->edid, src_size))
> + return -EINVAL;
> +
> + pr_info("sysfs written EDID is new default\n");
> + dlfb_ops_set_par(fb_info);
> + return src_size;
> }
>
> static ssize_t metrics_reset_store(struct device *fbdev,
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Laurent Pinchart @ 2012-03-21 14:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Florian,
On Wednesday 21 March 2012 14:26:01 Florian Tobias Schandinat wrote:
> On 03/21/2012 02:09 PM, Laurent Pinchart wrote:
> > On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
> >> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> >>> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> >>>> MERAM can be used for other IP blocks as well in the future.
> >>>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> >>>> This patch corrects dependency.
> >>>>
> >>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >>>> ---
> >>>> v3 -> v4
> >>>>
> >>>> - move config to before endpoint
> >>>
> >>> As the driver doesn't depend on FB and can also be used by other
> >>> subsystems, would it make sense to move it out of drivers/video/ ?
> >>> drivers/sh/ might be a candidate, although I think selecting a location
> >>> based on the platform is frowned upon (drivers/platform/x86 comes to
> >>> mind). There's probably a better location.
> >>
> >> Well, as long as it is related to video/graphic I think drivers/video is
> >> a good location. There are also backlight and console in that directory
> >> without being directly related to the framebuffer subsystem.
> >
> > The MERAM can also be used by the video engine unit (a memory-to-memory
> > format conversion block), the video processing unit (a multi-codec
> > module), the capture engine unit (camera interface), the JPEG engine unit
> > (a JPEG codec), ... Not all of those are related to display, although
> > they're all related to display, imaging, and or/video.
>
> I see, thanks for the explanation.
> I applied this patch so it can be used for such purposes without the
> dependency. If there will be a better place for it in the future we can
> move it than.
Sounds good to me. Thank you.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Florian Tobias Schandinat @ 2012-03-21 14:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Laurent,
On 03/21/2012 02:09 PM, Laurent Pinchart wrote:
> On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
>> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
>>> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
>>>> MERAM can be used for other IP blocks as well in the future.
>>>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
>>>> This patch corrects dependency.
>>>>
>>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>>> ---
>>>> v3 -> v4
>>>>
>>>> - move config to before endpoint
>>>
>>> As the driver doesn't depend on FB and can also be used by other
>>> subsystems, would it make sense to move it out of drivers/video/ ?
>>> drivers/sh/ might be a candidate, although I think selecting a location
>>> based on the platform is frowned upon (drivers/platform/x86 comes to
>>> mind). There's probably a better location.
>>
>> Well, as long as it is related to video/graphic I think drivers/video is
>> a good location. There are also backlight and console in that directory
>> without being directly related to the framebuffer subsystem.
>
> The MERAM can also be used by the video engine unit (a memory-to-memory format
> conversion block), the video processing unit (a multi-codec module), the
> capture engine unit (camera interface), the JPEG engine unit (a JPEG codec),
> ... Not all of those are related to display, although they're all related to
> display, imaging, and or/video.
I see, thanks for the explanation.
I applied this patch so it can be used for such purposes without the
dependency. If there will be a better place for it in the future we can
move it than.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Laurent Pinchart @ 2012-03-21 14:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Florian,
On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> > On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> >> MERAM can be used for other IP blocks as well in the future.
> >> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> >> This patch corrects dependency.
> >>
> >> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >> ---
> >> v3 -> v4
> >>
> >> - move config to before endpoint
> >
> > As the driver doesn't depend on FB and can also be used by other
> > subsystems, would it make sense to move it out of drivers/video/ ?
> > drivers/sh/ might be a candidate, although I think selecting a location
> > based on the platform is frowned upon (drivers/platform/x86 comes to
> > mind). There's probably a better location.
>
> Well, as long as it is related to video/graphic I think drivers/video is
> a good location. There are also backlight and console in that directory
> without being directly related to the framebuffer subsystem.
The MERAM can also be used by the video engine unit (a memory-to-memory format
conversion block), the video processing unit (a multi-codec module), the
capture engine unit (camera interface), the JPEG engine unit (a JPEG codec),
... Not all of those are related to display, although they're all related to
display, imaging, and or/video.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Florian Tobias Schandinat @ 2012-03-21 14:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Laurent,
On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> Hi Morimoto-san,
>
> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
>> MERAM can be used for other IP blocks as well in the future.
>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
>> This patch corrects dependency.
>>
>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> ---
>> v3 -> v4
>>
>> - move config to before endpoint
>
> As the driver doesn't depend on FB and can also be used by other subsystems,
> would it make sense to move it out of drivers/video/ ? drivers/sh/ might be a
> candidate, although I think selecting a location based on the platform is
> frowned upon (drivers/platform/x86 comes to mind). There's probably a better
> location.
Well, as long as it is related to video/graphic I think drivers/video is
a good location. There are also backlight and console in that directory
without being directly related to the framebuffer subsystem.
Best regards,
Florian Tobias Schandinat
>
>> drivers/video/Kconfig | 23 +++++++++++------------
>> 1 files changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 8951cbd..0fb9540 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
>> ---help---
>> Driver for the on-chip SH-Mobile HDMI controller.
>>
>> -config FB_SH_MOBILE_MERAM
>> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
>> - depends on FB_SH_MOBILE_LCDC
>> - default y
>> - ---help---
>> - Enable MERAM support for the SH-Mobile LCD controller.
>> -
>> - This will allow for caching of the framebuffer to provide more
>> - reliable access under heavy main memory bus traffic situations.
>> - Up to 4 memory channels can be configured, allowing 4 RGB or
>> - 2 YCbCr framebuffers to be configured.
>> -
>> config FB_TMIO
>> tristate "Toshiba Mobile IO FrameBuffer support"
>> depends on FB && MFD_CORE
>> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
>> source "drivers/video/logo/Kconfig"
>> endif
>>
>> +config FB_SH_MOBILE_MERAM
>> + tristate "SuperH Mobile MERAM read ahead support"
>> + depends on (SUPERH || ARCH_SHMOBILE)
>> + ---help---
>> + Enable MERAM support for the SuperH controller.
>> +
>> + This will allow for caching of the framebuffer to provide more
>> + reliable access under heavy main memory bus traffic situations.
>> + Up to 4 memory channels can be configured, allowing 4 RGB or
>> + 2 YCbCr framebuffers to be configured.
>> +
>> endmenu
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Laurent Pinchart @ 2012-03-21 13:49 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v3 -> v4
>
> - move config to before endpoint
As the driver doesn't depend on FB and can also be used by other subsystems,
would it make sense to move it out of drivers/video/ ? drivers/sh/ might be a
candidate, although I think selecting a location based on the platform is
frowned upon (drivers/platform/x86 comes to mind). There's probably a better
location.
> drivers/video/Kconfig | 23 +++++++++++------------
> 1 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 8951cbd..0fb9540 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
> ---help---
> Driver for the on-chip SH-Mobile HDMI controller.
>
> -config FB_SH_MOBILE_MERAM
> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
> - depends on FB_SH_MOBILE_LCDC
> - default y
> - ---help---
> - Enable MERAM support for the SH-Mobile LCD controller.
> -
> - This will allow for caching of the framebuffer to provide more
> - reliable access under heavy main memory bus traffic situations.
> - Up to 4 memory channels can be configured, allowing 4 RGB or
> - 2 YCbCr framebuffers to be configured.
> -
> config FB_TMIO
> tristate "Toshiba Mobile IO FrameBuffer support"
> depends on FB && MFD_CORE
> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
> source "drivers/video/logo/Kconfig"
> endif
>
> +config FB_SH_MOBILE_MERAM
> + tristate "SuperH Mobile MERAM read ahead support"
> + depends on (SUPERH || ARCH_SHMOBILE)
> + ---help---
> + Enable MERAM support for the SuperH controller.
> +
> + This will allow for caching of the framebuffer to provide more
> + reliable access under heavy main memory bus traffic situations.
> + Up to 4 memory channels can be configured, allowing 4 RGB or
> + 2 YCbCr framebuffers to be configured.
> +
> endmenu
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: provide default get_timings function for panels
From: Tomi Valkeinen @ 2012-03-21 13:11 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1331834424-485-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Thu, 2012-03-15 at 20:00 +0200, Grazvydas Ignotas wrote:
> With this we can eliminate some duplicate code in panel drivers.
> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
> tpo-td043mtea1 gain support of reading timings over sysfs.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> drivers/video/omap2/displays/panel-acx565akm.c | 7 -------
> drivers/video/omap2/displays/panel-generic-dpi.c | 7 -------
> drivers/video/omap2/displays/panel-n8x0.c | 8 --------
> drivers/video/omap2/displays/panel-taal.c | 8 --------
> drivers/video/omap2/dss/core.c | 2 ++
> drivers/video/omap2/dss/display.c | 7 +++++++
> drivers/video/omap2/dss/venc.c | 7 -------
> include/video/omapdss.h | 2 ++
> 8 files changed, 11 insertions(+), 37 deletions(-)
These two patches look fine to me, I'll apply to omapdss tree. Thanks!
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: check for matching memory size early
From: Tomi Valkeinen @ 2012-03-21 12:58 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1331253769-9770-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
Hi,
On Fri, 2012-03-09 at 02:42 +0200, Grazvydas Ignotas wrote:
> If the size of memory region that is being set up is the same as before,
> we don't have to do memory and layer busy checks.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> I'm not sure if this is semantically correct, but this helps to get
> some old programs working, that rely on old DSS version which didn't
> check for mmap lock, but incidentally they are using same size too..
Well, I wouldn't allow code like that if it was a new ioctl, but if, as
you say, the old omapfb worked that way, then I think it's better to do
things the same way.
I can see no harm in it, so I'll apply.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
From: Tomi Valkeinen @ 2012-03-21 12:50 UTC (permalink / raw)
To: Mark Brown
Cc: Florian Tobias Schandinat, Grazvydas Ignotas, linux-omap,
linux-fbdev
In-Reply-To: <1332169352-5076-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
On Mon, 2012-03-19 at 15:02 +0000, Mark Brown wrote:
> It is possible for regulator_enable() to fail and if it does fail that's
> generally a bad sign for anything we try to do with the hardware afterwards
> so check for and immediately return an error if regulator_enable() fails.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> index 32f3fcd..74c6b87 100644
> --- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> +++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> @@ -272,11 +272,14 @@ static const struct omap_video_timings tpo_td043_timings = {
> static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
> {
> int nreset_gpio = tpo_td043->nreset_gpio;
> + int r;
>
> if (tpo_td043->powered_on)
> return 0;
>
> - regulator_enable(tpo_td043->vcc_reg);
> + r = regulator_enable(tpo_td043->vcc_reg);
> + if (r != 0)
> + return r;
>
> /* wait for regulator to stabilize */
> msleep(160);
Thanks, I'll apply this series to omapdss tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox