1. 31 7月, 2014 1 次提交
  2. 02 6月, 2014 1 次提交
    • J
      drm/exynos: Fix PTN3460 dependency · b26c04f4
      Jean Delvare 提交于
      The following configuration options combination:
      
      CONFIG_DRM_EXYNOS_DP=y
      CONFIG_DRM_PTN3460=m
      
      currently leads to the following linker failure:
      
      drivers/built-in.o: In function `exynos_drm_attach_lcd_bridge':
      .../drivers/gpu/drm/exynos/exynos_dp_core.c:1004:
      undefined reference to `ptn3460_init'
      
      This is because ptn3460_init can't be implemented in a module while
      its caller is built into the kernel. So add the proper dependency in
      Kconfig so that the above can't happen.
      
      I moved DRM_PTN3460 earlier in Kconfig, next to the I2C helper module
      section, so that the user has a chance to select it before moving to
      the Exynos-specific section.
      
      IMHO the proper way to solve the problem would be to turn ptn3460 into
      a clean I2C driver, similar to the other I2C helper chip drivers. It's
      the only way to not sink into impossible-to-guess dependencies. Then
      ptn3460 could even be moved together with the other I2C helper chip
      drivers.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      b26c04f4
  3. 23 3月, 2014 1 次提交
  4. 23 12月, 2013 1 次提交
  5. 18 12月, 2013 2 次提交
    • T
      drm: Add panel support · aead40ea
      Thierry Reding 提交于
      Add a very simple framework to register and lookup panels. Panel drivers
      can initialize a DRM panel and register it with the framework, allowing
      them to be retrieved and used by display drivers. Currently only support
      for DPMS and obtaining panel modes is provided. However it should be
      sufficient to enable a large number of panels. The framework should also
      be easily extensible to support more sophisticated kinds of panels such
      as DSI.
      
      The framework hasn't been tied into the DRM core, even though it should
      be easily possible to do so if that's what we want. In the current
      implementation, display drivers can simple make use of it to retrieve a
      panel, obtain its modes and control its DPMS mode.
      
      Note that this is currently only tested on systems that boot from a
      device tree. No glue code has been written yet for systems that use
      platform data, but it should be easy to add.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      aead40ea
    • A
      drm: Add MIPI DSI bus support · 068a0023
      Andrzej Hajda 提交于
      MIPI DSI bus allows to model DSI hosts and DSI peripherals using the
      Linux driver model. DSI hosts are registered by the DSI host drivers.
      During registration DSI peripherals will be created from the children
      of the DSI host's device tree node. Support for registration from
      board-setup code will be added later when needed.
      
      DSI hosts expose operations which can be used by DSI peripheral drivers
      to access associated devices.
      Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      068a0023
  6. 31 10月, 2013 1 次提交
  7. 12 10月, 2013 3 次提交
    • R
      DRM: Armada: Add Armada DRM driver · 96f60e37
      Russell King 提交于
      This patch adds support for the pair of LCD controllers on the Marvell
      Armada 510 SoCs.  This driver supports:
      - multiple contiguous scanout buffers for video and graphics
      - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
        acceleration
      - dual lcd0 and lcd1 crt operation
      - video overlay on each LCD crt via DRM planes
      - page flipping of the main scanout buffers
      - DRM prime for buffer export/import
      
      This driver is trivial to extend to other Armada SoCs.
      
      Included in this commit is the core driver with no output support; output
      support is platform and encoder driver dependent.
      Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      96f60e37
    • D
      drm/i915: Kconfig option to disable the legacy fbdev support · 4520f53a
      Daniel Vetter 提交于
      Boots Just Fine (tm)!
      
      The only glitch seems to be that at least on Fedora the boot splash
      gets confused and doesn't display much at all.
      
      And since there's no ugly console flickering anymore in between, the
      flicker while switching between X servers (VT support is still enabled)
      is even more jarring.
      
      Also, I'm unsure whether we don't need to somehow kick out vgacon, now
      that nothing else gets in the way. But stuff seems to work, so I
      don't care. Also everything still works as well with VGA_CONSOLE=n
      
      Also the #ifdef mess needs a bit of a cleanup, follow-up patches will
      do just that.
      
      To keep the Kconfig tidy, extract all the i915 options into its own
      file.
      
      v2:
      - Rebase on top of the preliminary hw support option and the
        intel_drv.h cleanup.
      - Shut up warnings in i915_debugfs.c
      
      v3: Use the right CONFIG variable, spotted by Chon Ming.
      
      Cc: Lee, Chon Ming <chon.ming.lee@intel.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4520f53a
    • D
      drm: Add separate Kconfig option for fbdev helpers · 92b6f89f
      Daniel Vetter 提交于
      For drivers which might want to disable fbdev legacy support.
      
      Select the new option in all drivers for now, so this shouldn't result
      in any change. Drivers need some work anyway to make fbdev support
      optional (if they have it implemented, that is), so the recommended
      way to expose this is by adding per-driver options. At least as long
      as most drivers don't support disabling the fbdev support.
      
      v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
      driver can already take advantage of this, which allows us to build
      msm without any fbdev depencies in the kernel!
      
      v3: Move the MODULE_* stuff from the fbdev helper file to
      drm_crtc_helper.c.
      
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Acked-by: NDave Airlie <airlied@linux.ie>
      Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      92b6f89f
  8. 25 8月, 2013 1 次提交
    • R
      drm/msm: basic KMS driver for snapdragon · c8afe684
      Rob Clark 提交于
      The snapdragon chips have multiple different display controllers,
      depending on which chip variant/version.  (As far as I can tell, current
      devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
      then external to the display controller are HDMI, DSI, etc. blocks which
      may be shared across devices which have different display controller
      blocks.
      
      To more easily add support for different display controller blocks, the
      display controller specific bits are split out into a "kms" module,
      which provides the kms plane/crtc/encoder objects.
      
      The external HDMI, DSI, etc. blocks are part encoder, and part connector
      currently.  But I think I will pull in the drm_bridge patches from
      chromeos tree, and split them into a bridge+connector, with the
      registers that need to be set in modeset handled by the bridge.  This
      would remove the 'msm_connector' base class.  But some things need to be
      double checked to make sure I could get the correct ON/OFF sequencing..
      
      This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
      (part of MDP4 block), and hdmi.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      c8afe684
  9. 22 8月, 2013 1 次提交
  10. 19 8月, 2013 1 次提交
    • G
      drm: DRM should depend on HAS_DMA · cc6a36f2
      Geert Uytterhoeven 提交于
      If NO_DMA=y:
      
      drivers/built-in.o: In function `__drm_pci_free':
      drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
      drivers/built-in.o: In function `drm_pci_alloc':
      drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
      drivers/built-in.o: In function `drm_gem_unmap_dma_buf':
      drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg'
      drivers/built-in.o: In function `drm_gem_map_dma_buf':
      drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg'
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      cc6a36f2
  11. 28 6月, 2013 1 次提交
  12. 27 6月, 2013 1 次提交
  13. 22 4月, 2013 1 次提交
  14. 12 4月, 2013 1 次提交
    • D
      drm: add new QXL driver. (v1.4) · f64122c1
      Dave Airlie 提交于
      QXL is a paravirtual graphics device used by the Spice virtual desktop
      interface.
      
      The drivers uses GEM and TTM to manage memory, the qxl hw fencing however
      is quite different than normal TTM expects, we have to keep track of a number
      of non-linear fence ids per bo that we need to have released by the hardware.
      
      The releases are freed from a workqueue that wakes up and processes the
      release ring.
      
      releases are suballocated from a BO, there are 3 release categories, drawables,
      surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling.
      
      The hardware also have a surface id tracking mechnaism and the driver encapsulates it completely inside the kernel, userspace never sees the actual hw surface
      ids.
      
      This requires a newer version of the QXL userspace driver, so shouldn't be
      enabled until that has been placed into your distro of choice.
      
      Authors: Dave Airlie, Alon Levy
      
      v1.1: fixup some issues in the ioctl interface with padding
      v1.2: add module device table
      v1.3: fix nomodeset, fbcon leak, dumb bo create, release ring irq,
            don't try flush release ring (broken hw), fix -modesetting.
      v1.4: fbcon cpu usage reduction + suitable accel flags.
      Signed-off-by: NAlon Levy <alevy@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f64122c1
  15. 22 2月, 2013 1 次提交
  16. 20 2月, 2013 1 次提交
    • R
      drm/tilcdc: add TI LCD Controller DRM driver (v4) · 16ea975e
      Rob Clark 提交于
      A simple DRM/KMS driver for the TI LCD Controller found in various
      smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
      CMA helpers.  Currently only the TFP410 DVI encoder is supported
      (tested with beaglebone + DVI cape).  There are also various LCD
      displays, for which support can be added (as I get hw to test on),
      and an external i2c HDMI encoder found on some boards.
      
      The display controller supports a single CRTC.  And the encoder+
      connector are split out into sub-devices.  Depending on which LCD
      or external encoder is actually present, the appropriate output
      module(s) will be loaded.
      
      v1: original
      v2: fix fb refcnting and few other cleanups
      v3: get +/- vsync/hsync from timings rather than panel-info, add
          option DT max-bandwidth field so driver doesn't attempt to
          pick a display mode with too high memory bandwidth, and other
          small cleanups
      v4: remove some unneeded stuff from panel-info struct, properly
          set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: NKoen Kooi <koen@dominion.thruhere.net>
      16ea975e
  17. 17 2月, 2013 1 次提交
    • R
      drm/omap: move out of staging · 8bb0daff
      Rob Clark 提交于
      Now that the omapdss interface has been reworked so that omapdrm can use
      dispc directly, we have been able to fix the remaining functional kms
      issues with omapdrm.  And in the mean time the PM sequencing and many
      other of that open issues have been solved.  So I think it makes sense
      to finally move omapdrm out of staging.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      8bb0daff
  18. 08 2月, 2013 1 次提交
  19. 01 2月, 2013 1 次提交
  20. 20 11月, 2012 1 次提交
  21. 18 9月, 2012 3 次提交
  22. 04 9月, 2012 1 次提交
    • S
      drm: udl: usb: Fix recursive Kconfig dependency · 95ca19cf
      Sedat Dilek 提交于
      In drivers/usb/Kconfig "config USB_ARCH_HAS_HCD" is within "if USB_SUPPORT"
      statement.
      
      In drivers/gpu/drm/Kconfig "config DRM_USB" depends on USB_ARCH_HAS_HCD
      but selects USB_SUPPORT which leads to the error for udl Kconfig:
      
      $ yes "" | make oldconfig
      scripts/kconfig/conf --oldconfig Kconfig
      drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
      drivers/gpu/drm/udl/Kconfig:1:  symbol DRM_UDL depends on USB_ARCH_HAS_HCD
      drivers/usb/Kconfig:76: symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
      drivers/usb/Kconfig:58: symbol USB_SUPPORT is selected by DRM_USB
      drivers/gpu/drm/Kconfig:22:     symbol DRM_USB is selected by DRM_UDL
      
      Fix this by changing from select to depends on USB_SUPPORT in
      "config DRM_USB".
      
      This is a follow-up fix to df0b3443
      in Dave's drm-next GIT branch.
      
      [ v2: Restore old status, but change from select to depends on USB_SUPPORT ]
      Signed-off-by: NSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      95ca19cf
  23. 24 8月, 2012 1 次提交
    • S
      drm/usb: select USB_SUPPORT in Kconfig · df0b3443
      Sachin Kamat 提交于
      DRM_USB selects USB. However, USB depends on USB_SUPPORT and USB_ARCH_HAS_HCD.
      Thus, selecting USB_SUPPORT in Kconfig avoids the following warning
      (detected when DisplayLink was selected using exynos4_defconfig):
      
      warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB && JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 && IR_STREAMZAP && IR_IGUANA && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD)
      Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      df0b3443
  24. 21 8月, 2012 1 次提交
    • G
      gpu/mfd/usb: Fix USB randconfig problems · 8f057d7b
      Guenter Roeck 提交于
      Fix config warning:
      
      warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies
      (USB_SUPPORT && USB_ARCH_HAS_HCD)
      
      and build error:
      ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined!
      
      by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB.
      
      This exposes:
      drivers/video/Kconfig:36:error: recursive dependency detected!
      drivers/video/Kconfig:36:       symbol FB is selected by DRM_KMS_HELPER
      drivers/gpu/drm/Kconfig:28:     symbol DRM_KMS_HELPER is selected by DRM_UDL
      drivers/gpu/drm/udl/Kconfig:1:  symbol DRM_UDL depends on USB_ARCH_HAS_HCD
      drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI
      drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C
      drivers/i2c/Kconfig:5:  symbol I2C is selected by FB_DDC
      drivers/video/Kconfig:86:       symbol FB_DDC is selected by FB_CYBER2000_DDC
      drivers/video/Kconfig:385:      symbol FB_CYBER2000_DDC depends on FB_CYBER2000
      drivers/video/Kconfig:373:      symbol FB_CYBER2000 depends on FB
      
      which is due to drivers/usb/Kconfig:
      config USB_ARCH_HAS_OHCI
      	...
      	default y if ARCH_PNX4008 && I2C
      
      Fix by dropping I2C from the above dependency; logic is that this is not a
      platform dependency but a configuration dependency: the _architecture_ still
      supports USB even is I2C is not selected.
      
      This exposes:
      drivers/video/Kconfig:36:error: recursive dependency detected!
      drivers/video/Kconfig:36:       symbol FB is selected by DRM_KMS_HELPER
      drivers/gpu/drm/Kconfig:28:     symbol DRM_KMS_HELPER is selected by DRM_UDL
      drivers/gpu/drm/udl/Kconfig:1:  symbol DRM_UDL depends on USB_ARCH_HAS_HCD
      drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI
      drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB
      drivers/mfd/Kconfig:396:        symbol MFD_TC6393XB depends on GPIOLIB
      drivers/gpio/Kconfig:35:        symbol GPIOLIB is selected by FB_VIA
      drivers/video/Kconfig:1560:     symbol FB_VIA depends on FB
      
      which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on
      it.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f057d7b
  25. 17 5月, 2012 3 次提交
    • D
      drm/kms: driver for virtual cirrus under qemu · f9aa76a8
      Dave Airlie 提交于
      This is the initial driver for emulated cirrus GPU found in qemu.
      This driver only supports the emulated GPU and doesn't attempt
      to bind to any real cirrus GPUs.
      
      This driver is intended to be used with xf86-video-modesetting in userspace.
      It requires at least version 0.3.0
      
      This follow the same design as ast and mgag200, and is based on work
      done by Matthew Garrett previously.
      
      This GPU has no hw cursor, and it can't scanout 32-bpp, only packed 24-bpp.
      i.e. it sucks.
      Reviewed-by: NAdam Jackson <ajax@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f9aa76a8
    • D
      mgag200: initial g200se driver (v2) · 414c4531
      Dave Airlie 提交于
      This is a driver for the G200 server engines chips,
      it doesn't driver any of the Matrix G series desktop cards.
      
      It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards.
      
      Its based on previous work done my Matthew Garrett but remodelled
      to follow the same style and flow as the AST server driver. It also
      works along the same lines as the AST server driver wrt memory management.
      
      There is no userspace driver planned, xf86-video-modesetting should be used.
      It also appears these GPUs have no ARGB hw cursors.
      
      v2: add missing tagfifo reset + G200 SE memory bw setup pieces.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      414c4531
    • D
      drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2) · 312fec14
      Dave Airlie 提交于
      This is the initial driver for the Aspeed Technologies chips found in
      servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It
      doesn't support the AST11xx due to lack of hw to test it on, and them requiring
      different codepaths.
      
      This driver is intended to be used with xf86-video-modesetting in userspace.
      
      This driver has a slightly different design than other KMS drivers, but
      future server chips will probably share similiar setup. As these GPUs commonly
      have low video RAM, it doesn't make sense to put the kms console in VRAM
      always. This driver places the kms console into system RAM, and does dirty
      updates to a copy in video RAM. When userspace sets a new scanout buffer,
      it forcefully evicts the video RAM console, and X can create a framebuffer
      that can use all of of video RAM.
      
      This driver uses TTM but in a very simple fashion to control the eviction
      to system RAM of the console, and multiple servers.
      
      v2: add s/r support, fix Kconfig.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      312fec14
  26. 30 3月, 2012 1 次提交
  27. 22 3月, 2012 1 次提交
  28. 20 3月, 2012 2 次提交
    • C
      drm: allow loading an EDID as firmware to override broken monitor · da0df92b
      Carsten Emde 提交于
      Broken monitors and/or broken graphic boards may send erroneous or no
      EDID data. This also applies to broken KVM devices that are unable to
      correctly forward the EDID data of the connected monitor but invent
      their own fantasy data.
      
      This patch allows to specify an EDID data set to be used instead of
      probing the monitor for it. It contains built-in data sets of frequently
      used screen resolutions. In addition, a particular EDID data set may be
      provided in the /lib/firmware directory and loaded via the firmware
      interface. The name is passed to the kernel as module parameter of the
      drm_kms_helper module either when loaded
        options drm_kms_helper edid_firmware=edid/1280x1024.bin
      or as kernel commandline parameter
        drm_kms_helper.edid_firmware=edid/1280x1024.bin
      
      It is also possible to restrict the usage of a specified EDID data set
      to a particular connector. This is done by prepending the name of the
      connector to the name of the EDID data set using the syntax
        edid_firmware=[<connector>:]<edid>
      such as, for example,
        edid_firmware=DVI-I-1:edid/1920x1080.bin
      in which case no other connector will be affected.
      
      The built-in data sets are
      Resolution    Name
      --------------------------------
      1024x768      edid/1024x768.bin
      1280x1024     edid/1280x1024.bin
      1680x1050     edid/1680x1050.bin
      1920x1080     edid/1920x1080.bin
      
      They are ignored, if a file with the same name is available in the
      /lib/firmware directory.
      
      The built-in EDID data sets are based on standard timings that may not
      apply to a particular monitor and even crash it. Ideally, EDID data of
      the connected monitor should be used. They may be obtained through the
      drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
      of a correctly working graphics adapter.
      
      It is even possible to specify the name of an EDID data set on-the-fly
      via the /sys/module interface, e.g.
      echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
      The new screen mode is considered when the related kernel function is
      called for the first time after the change. Such calls are made when the
      X server is started or when the display settings dialog is opened in an
      already running X server.
      Signed-off-by: NCarsten Emde <C.Emde@osadl.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      da0df92b
    • D
      drm/usb: move usb support into a separate module · 9c1dfc55
      Dave Airlie 提交于
      In order to satisfy all the various Kconfig options between
      USB and DRM, we need to split the USB code out into a separate module
      and export symbols to it.
      
      This fixes build problems in -next reported by sfr.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9c1dfc55
  29. 15 3月, 2012 1 次提交
    • D
      drm/udl: initial UDL driver (v4) · 5320918b
      Dave Airlie 提交于
      This is an initial drm/kms driver for the displaylink devices.
      
      Supports fb_defio,
      supports KMS dumb interface
      supports 24bpp via conversion to 16bpp, hw can do this better.
      supports hot unplug using new drm core features.
      
      On an unplug, it disables connector polling, unplugs connectors
      from sysfs, unplugs fbdev layer (using Kay's API), drops all the
      USB device URBs, and call the drm core to unplug the device.
      
      This driver is based in large parts on udlfb.c so I've licensed
      it under GPLv2.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5320918b
  30. 16 11月, 2011 1 次提交
  31. 11 11月, 2011 2 次提交