{"shas":[["3f10402b83d160477c13f33ec11cdff35b8b641e","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","omap_gpu drm display driver\n\nA DSS based DRM display driver, which provides a plugin interface for\n3d/2d accelerators to register.  The core driver handles construction\nof CRTC/encoder/connectors to represent the hardware, and support KMS.\nThis driver replaces omapfb.. omap_gpu drm driver allocates framebuffer\nmemory and implements (with the help of drm_fb_helper) the legacy fbdev\ninterface.\n\nThe driver maps CRTCs to overlays, encoders to overlay-managers, and\nconnectors to dssdev's.\n\nTo set vram on the command-line (bootargs):\n\n  omapgpu.vram=0:32M\n\n(same syntax as omapfb but use omapgpu module name instead)\n\nTo set default resolution on command-line, use the normal video= line,\nsuch as:\n\n  video=HDMI Type A-1:800x600@60\n\nnote: sometimes there is an issue with the hdmi driver overriding the\nset resolution when it gets a hotplug event and reads the EDID.  The\nhdmi driver will need to be tamed so that it does not override the\ncurrently set timings, at least not as long as they are still a valid\nchoice according to the EDID.\n\nAnd of course, to enable debug:\n\n  drm.debug=7\n\nThe omap_gpu drm driver supports using platform_data to configure which\nomap_gpu devices are assigned which overlays/managers/devices.  If\nmultiple devices are registered, each one creates it's own framebuffer\nand fbdev.  This allows for multiple independent display contexts (like\nwith the old omapfb driver) in cases where you don't want to share one\nvirtual framebuffer across multiple displays.","Rob Clark"],["35a4e1b03b4ba96f1ab6b623dba0058f617098fd","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","pvr: support to register as a plugin for omap_gpu drm driver\n\nIncludes a new ioctl cmd to re-sync state with display, to properly handle\nresizing of frame-buffer.","Rob Clark"],["1101d5a6fce35cffa95bf1b48a864b5181755aa2","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","pvr: restrict visibility of DC devices to corresponding drm_device instance\n\nAssociate a handle to display-class devices, so visibility can be restricted\nto certain drm_device instances.  So now, you can build kernel with two\ndrm_device instances, and two corresponding framebuffer instances.  And when\nuserspace enumerates the DC devices it will see only the one corresponding\nto the drm_device that it has opened.\n\nSo now you can either build the kernel with one drm_device, with the fb\npossibly spanning multiple independent displays, but acting as a single\nvirtual display.  Or with multiple drm_devices acting as multiple independent\ndisplays.  In either case, when userspace enumerates the display-class\ndevices, they see only a single device corresponding to the single fbdev\nassociated with that drm_device.","Rob Clark"],["1c9e5cebad19461624948950046611c2e151f84a","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","setup multiple drm devices\n\nRegister multiple drm devices and use platform_data to configure who\nuses which dss pipes/managers/devices.","Rob Clark"],["1708a1dfc8b562de9da14ad9eca31f1747b4dd7f","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","special hack for android\n\nAndroid is still using the old pvrsrvkm driver name, and I'm not sure\nhow to rebuild userspace to fix this.. so for now a hack to use the\nold name..","Rob Clark"],["6491fad7efc5b3fd9238507faf520cedaa537fbe","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","xxx hack to avoid rebuilding surfaceflinger\n\nrevert this patch when android ddk is rebuilt to use busid\n\"platform:pvrsrvkm:00\" instead of \"platform:pvrsrvkm\"","Rob Clark"],["78f8147a1a0eb1abd69b64ecf72c99f4b6626e3c","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","omap:dss: don't enable alphablender on omap4\n\nAlpha blending is the default behavior with color formats that have\nan alpha channel.  But if the alphablender bits are enabled, that\nputs DSS in a omap3 legacy mode which disabled z-order.","Rob Clark"],["778fcfcd96444fb85ec679137ffdb3f07a0cb1f7","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","fix number of omap_vout resources\n\nDepending on whether kernel is built with omapfb or omapgpu, it needs to\nconsider CONFIG_FB_OMAP2_NUM_FBS or CONFIG_DRM_OMAP_NUM_CRTCS to know how\nmany DSS pipes are used for framebuffers.","Rob Clark"],["e050490f631b89c1b1c49f4678d779883eedbec9","6754f5a2cf34245b44e327d3faebd2daff9d5b3a@ti.com","omap4: pandaboard: add defconfig for OMAP4 PandaBoard","GeethaT"],["475e853b70b9a91600c7aa446a50c2f5f3bb6bd0","3c9dc4f5198388a567917623a16a819b5c680f4c@ti.com","omap4: pandaboard: don't enable auxclk3 which is needed for ehci","David Anders"],["f41b45dfdf41a0a8577271dabcafedf3985ebfa6","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","Revert \"xxx hack to avoid rebuilding surfaceflinger\"\n\nThis reverts commit 6491fad7efc5b3fd9238507faf520cedaa537fbe.","Rob Clark"],["73bb7177d001e2ee1e1ffcac34d3da852a8ff13f","ddc26675d69d78ffca8b6ae1b2fdb1697c41716f@ti.com","UBUNTU: SAUCE: smsc95xx: Add module parameter to override MAC address\n\nDefine a new module parameter 'macaddr' to override the MAC address\nfetched either from eeprom, or randomly generated.\n\nThe expected MAC address shall be in the 01:23:45:67:89:AB format.\n\nSigned-off-by: Sebastien Jan <s-jan@ti.com>","Sebastien Jan"],["0bb0fee0b5aa94e1195d8f3c9952f886542ba135","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","Revert \"drm: workaround for userspace not calling setversion\"\n\nThis reverts commit bee2584fba3e253500bfe696e681f56b6d2b99ee.","Rob Clark"],["5a542edb1e4187ac9fbd8058ae9420647a80624c","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","omap_gpu: fix for NPE","Rob Clark"],["91a1d3926593646705df7cf845fcf000b456c6da","7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@ti.com","move omap_gpu configuration to board file","Rob Clark"],["2d43dc1327faaa018f8d1eb33cec0e55b283ca0b","25f43eec7da9e3fd28f2b3898351e29af590dc06@ti.com","Support of multiple sync objects of SGXSubmitTransferKM\n\nThis is a fixed and optimized version of SGXSubmitTransferKM\npatch provided by IMG. This change allows for multiple source\nand destination sync objects to be supported allowing for a\nmore efficient surface management. The fixes and optimizations\nwere in the array use. More optimizations are required to\nreduce the overhead of the iterations traversing all sync\nobjects.\n\nChange-Id: I415228ba3eef33552d2a6275428f0e399d9ac37e\nReviewed-on: http://dlegerr.ext.ti.com/gerrit/omap/203\nTested-by: Ian Elliott <ian.elliott@intelligraphics.com>\nReviewed-by: Ian Elliott <ian.elliott@intelligraphics.com>\nReviewed-by: Jeff McGee <j-mcgee@ti.com>","Tony Zlatinski"]],"repo":"robclark/kernel-omap4","actor":"robclark","ref":"refs/heads/omap_gpu-android","size":16,"head":"2d43dc1327faaa018f8d1eb33cec0e55b283ca0b","actor_gravatar":"7e10e70c29be7a086a9e8ce9d51702b5","push_id":29117292}