- 25 Jul, 2019 15 commits
-
-
Sam Ravnborg authored
The DRM_READ, DRM_WRITE macros comes from the deprecated drm_os_linux.h header file. Remove their use to remove this dependency. Replace the use of the macros with static inline variants. v4: - Use a more standard via_write8_mask() function (Emil) v3: - Use static inline functions, rather than macros (Emil) - Use dedicated mask variants for byte access (Emil) Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Cc: Kevin Brace <kevinbrace@gmx.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com> Cc: Mike Marshall <hubcap@omnibond.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michel Dänzer <michel@daenzer.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190723200944.17285-2-sam@ravnborg.org
-
Olivier Moysan authored
Implement get_dai_id callback of audio HDMI codec to support ASoC audio graph card. HDMI audio output has to be connected to sii902x port 3. get_dai_id callback maps this port to ASoC DAI index 0. Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Acked-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1562141052-26221-1-git-send-email-olivier.moysan@st.com
-
Olivier Moysan authored
The master clock on i2s bus is not mandatory, as sii902X internal PLL can be used instead. Make use of mclk optional. Signed-off-by:
-
Olivier Moysan authored
As stated in SiL9022/24 datasheet, master clock is not required for I2S. Make mclk property optional in DT bindings. Fixes: 3f18021f ("dt-bindings: display: sii902x: Add HDMI audio bindings") Signed-off-by:
-
Olivier Moysan authored
Add devm_clk_get call to retrieve reference to master clock. Fixes: ff578163 ("drm/bridge: sii902x: Implement HDMI audio support") Signed-off-by:
-
Ahmad Fatoum authored
To properly synchronize with other devices the fence from the GEM object backing the framebuffer needs to be attached to the atomic state, so the commit work can wait on fence signaling. Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
-
Noralf Trønnes authored
tinydrm is just a collection of tiny drivers now. Add T: drm-misc entry for tinydrm drivers that lacks it. Cc: David Lechner <david@lechnology.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
David Lechner <david@lechnology.com> Acked-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-10-noralf@tronnes.org
-
Noralf Trønnes authored
This moves mipi-dbi to be a core helper with the name drm_mipi_dbi. Fixup include's in drivers. Move the docs entry and delete tinydrm.rst. Delete the last tinydrm todo entry. v2: Make DRM_MIPI_DBI tristate to enable it being built as a module. Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
mipi-dbi uses several KMS helper functions but that build dependency is not expressed. Select DRM_KMS_HELPER to fix that. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Noralf Trønnes authored
The mipi_dbi helper is missing a dependency on DRM_KMS_HELPER and putting that in revealed this problem: drivers/video/fbdev/Kconfig:12:error: recursive dependency detected! drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:75: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:69: symbol DRM_KMS_HELPER is selected by TINYDRM_MIPI_DBI drivers/gpu/drm/tinydrm/Kconfig:11: symbol TINYDRM_MIPI_DBI is selected by TINYDRM_HX8357D drivers/gpu/drm/tinydrm/Kconfig:15: symbol TINYDRM_HX8357D depends on BACKLIGHT_CLASS_DEVICE drivers/video/backlight/Kconfig:144: symbol BACKLIGHT_CLASS_DEVICE is selected by FB_BACKLIGHT drivers/video/fbdev/Kconfig:187: symbol FB_BACKLIGHT depends on FB A symbol that selects DRM_KMS_HELPER can not depend on BACKLIGHT_CLASS_DEVICE. The reason for this is that DRM_KMS_FB_HELPER selects FB instead of depending on it. The tinydrm drivers have somehow gotten away with depending on BACKLIGHT_CLASS_DEVICE because DRM_TINYDRM selects DRM_KMS_HELPER and the drivers depend on that symbol. An audit shows that all DRM drivers that select DRM_KMS_HELPER and use BACKLIGHT_CLASS_DEVICE, selects it: DRM_TILCDC, DRM_GMA500, DRM_SHMOBILE, DRM_NOUVEAU, DRM_FSL_DCU, DRM_I915, DRM_RADEON, DRM_AMDGPU, DRM_PARADE_PS8622 Documentation/kbuild/kconfig-language.txt has a note regarding select: 1. 'select should be used with care since it doesn't visit dependencies.' This is not a problem since BACKLIGHT_CLASS_DEVICE doesn't have any dependencies. 2. 'In general use select only for non-visible symbols' BACKLIGHT_CLASS_DEVICE is user visible. The real solution to this would be to have DRM_KMS_FB_HELPER depend on the user visible symbol FB. That is a can of worms I'm not willing to tackle. I fear that such a change will result in me handling difficult fallouts for the next weeks. So I'm following DRM suite here. Signed-off-by:
-
Noralf Trønnes authored
mipi-dbi depends on the CMA helper through its use of drm_fb_cma_get_gem_obj(). This is an unnecessary dependency to drag in for drivers that only want to use the MIPI DBI interface part. Avoid this by open coding the function. Signed-off-by:
-
Noralf Trønnes authored
Split struct mipi_dbi into an interface part and a display pipeline part. The interface part can be used by drivers that need to initialize the controller, but that won't upload the framebuffer over this interface. MIPI DBI supports 3 interface types: - A. Motorola 6800 type parallel bus - B. Intel 8080 type parallel bus - C. SPI type with 3 options: I've embedded the SPI type specifics in the mipi_dbi struct to avoid adding unnecessary complexity. If more interface types will be supported in the future, the type specifics might have to be split out. Rename functions to match the new struct mipi_dbi_dev: - drm_to_mipi_dbi() -> drm_to_mipi_dbi_dev(). - mipi_dbi_init*() -> mipi_dbi_dev_init*(). Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
struct mipi_dbi is going to be split into an interface part and a display pipeline part. The interface part can be used by drivers that need to initialize the controller, but that won't upload the framebuffer over this interface. tinydrm uses the variable name 'mipi' but this is not a good name since MIPI refers to a lot of standards. This patch changes the variable name to 'dbidev' where it refers to the pipeline part of struct mipi_dbi. Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
struct mipi_dbi is going to be split into an interface part and a display pipeline part. The interface part can be used by drivers that need to initialize the controller, but that won't upload the framebuffer over this interface. tinydrm uses the variable name 'mipi' but this is not a good name since MIPI refers to a lot of standards. This patch changes the variable name to 'dbi' where it refers to the interface part of struct mipi_dbi. Functions that use both future parts will have both variables temporarily pointing to the same structure. Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
cmdlock protects command execution so put it in mipi_dbi_spi_init() where it conceptually belongs. This is prep work for the splitting of struct mipi_dbi. Reviewed-by:
-
- 24 Jul, 2019 3 commits
-
-
Thomas Zimmermann authored
Currently the displayed cursor buffer might be evicted from video memory. Not unpinning the BO fixes this problem. At this point, pixels_current also references the BO and it will be unpinned during the next cursor update. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
-
Thomas Zimmermann authored
The hardware requires the correct memory address of the buffer. Currently the same BO's address is programmed unconditionally, so only every second cursor update actually becomes visible. Signed-off-by:
-
Thomas Zimmermann authored
The cursor BO has to be pinned to video ram while it's being displayed. With the current code, the BO might be pinned to system memory instead. The patch fixes this problem. Signed-off-by:
-
- 23 Jul, 2019 22 commits
-
-
Marko Kohtala authored
Various displays have differences that only mean initializing the display driver IC with different fixed register values. Defining these in devicetree offers easier way to adapt the driver to new displays than requiring a patch to the kernel. This adds devicetree properties needed to make the initialization match the example setup as offered by Densitron for their 128x36 display. It also makes some old one bit parameter handling a little cleaner. Signed-off-by:
Marko Kohtala <marko.kohtala@okoko.fi> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Michal Vokáč <michal.vokac@ysoft.com> [b.zolnierkie: fix parenthesis alignment] Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-7-marko.kohtala@okoko.fi
-
Marko Kohtala authored
Document new bindings for adapting ssd1307fb driver to new displays. Signed-off-by:
Rob Herring <robh@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Michal Vokáč <michal.vokac@ysoft.com> Signed-off-by:
-
Marko Kohtala authored
Some displays have dimensions that are not multiple of eight, for example height of 36, but the driver divided the dimensions by 8. Defining display to the next multiple of 8 is not good as then the display registers get configured to dimensions that do not match. This contradicts intructions by some display manufacturers. Use DIV_ROUND_UP to multiple of 8 when needed so correct values can be used. The ssd1307fb_update_display bit reordering receives a simplification in the process. Signed-off-by:
-
Marko Kohtala authored
The page_offset was only applied to the end of the page range. This caused the display updates to cause a scrolling effect on the display because the amount of data written to the display did not match the range display expected. Fixes: 301bc067 ("video: ssd1307fb: Make use of horizontal addressing mode") Signed-off-by:
-
Marko Kohtala authored
coccicheck reported unneeded semicolons. Remove them. Signed-off-by:
-
Marko Kohtala authored
sparse reported incorrect type due to different address spaces. The screen_base is __iomem, but the memory is not from a device so we can use screen_buffer instead and avoid some type casts. Signed-off-by:
-
Fuqian Huang authored
In commit 518a2f19 ("dma-mapping: zero memory returned from dma_alloc_*"), dma_alloc_coherent has already zeroed the memory. So memset is not needed. Signed-off-by:
Fuqian Huang <huangfq.daxian@gmail.com> Reviewed-by:
-
Souptick Joarder authored
This is dead code since 3.15. If there is no plan to use it further, this can be removed forever. Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Sabyasachi Gupta <sabyasachi.linux@gmail.com> Signed-off-by:
-
Souptick Joarder authored
Minor cleanup to remove extra return statement. Signed-off-by:
-
Christoph Hellwig authored
au1200fb allocates DMA memory using DMA_ATTR_NON_CONSISTENT, but never calls dma_cache_sync to synchronize the memory between the CPU and the device. If it was use on a not cache coherent bus that would be fatal, but as far as I can tell from the naming and the mips platform implementation it always is used in cache coherent systems. Remove the DMA_ATTR_NON_CONSISTENT flag, which is a no-op in that case. Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by:
-
Colin Ian King authored
Variable err is initialized to a value that is never read and it is re-assigned later. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Noralf Trønnes authored
tinydrm_display_pipe_init() has only one user now, so move it to mipi-dbi. Changes: - Remove drm_connector_helper_funcs.detect, it's always connected. - Store the connector and mode in mipi_dbi instead of it's own struct. Otherwise remove some leftover tinydrm-helpers.h inclusions. Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
The MIPI DBI standard support more pixel formats than what this helper supports. Add an init function that lets the driver use different format(s). This avoids open coding mipi_dbi_init() in st7586. st7586 sets preferred_depth but this is not necessary since it only supports one format. v2: Forgot to remove the mipi->rotation assignment in st7586, mipi_dbi_init_with_formats() handles it. Cc: David Lechner <david@lechnology.com> Acked-by: -
Noralf Trønnes authored
tinydrm.ko is going away so let's implement a connector. Reviewed-by:
-
Noralf Trønnes authored
The tinydrm helper is going away so move it into the only user mipi-dbi. Reviewed-by:
-
Noralf Trønnes authored
This is only used by mipi-dbi drivers so move it there. The reason this isn't moved to the SPI subsystem is that it will in a later patch pass a dummy rx buffer for SPI controllers that need this. Low memory boards (64MB) can run into a problem allocating such a "large" contiguous buffer on every transfer after a long up time. This leaves a very specific use case, so we'll keep the function here. mipi-dbi will first go through a refactoring though, before this will be done. Remove SPI todo entry now that we're done with the tinydrm.ko SPI code. v2: Drop moving the mipi_dbi_spi_init() declaration (Sam) Cc: David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
Prep work before moving the function to mipi-dbi. tinydrm_spi_transfer() was made to support one class of drivers in drivers/staging/fbtft that has not been converted to DRM yet, so strip away the unused functionality: - Start byte (header) is not used. - No driver relies on the automatic 16-bit byte swapping on little endian machines with SPI controllers only supporting 8 bits per word. Other changes: - No need to initialize ret - No need for the WARN since mipi-dbi only uses 8 and 16 bpw. - Use spi_message_init_with_transfers() Cc: David Lechner <david@lechnology.com> Acked-by:
-
Noralf Trønnes authored
spi-bcm2835 can handle >64kB buffers now so there is no need to check ->max_dma_len. The tinydrm_spi_max_transfer_size() max_len argument is not used by any callers, so not needed. Then we have the spi_max module parameter. It was added because staging/fbtft has support for it and there was a report that someone used it to set a small buffer size to avoid popping on a USB soundcard on a Raspberry Pi. In hindsight it shouldn't have been added, I should have waited for it to become a problem first. I don't know it anyone is actually using it, but since tinydrm_spi_transfer() is being moved to mipi-dbi, I'm taking the opportunity to remove it. I'll add it back to mipi-dbi if someone complains. With that out of the way, spi_max_transfer_size() can be used instead. The chosen 16kB buffer size for Type C Option 1 (9-bit) interface is somewhat arbitrary, but a bigger buffer will have a miniscule impact on transfer speed, so it's probably fine. Acked-by:
-
Noralf Trønnes authored
The SPI event tracing can dump the buffer now so no need for this. Remove the debug print from tinydrm_spi_transfer() since this info can be gleaned from the trace event. Reviewed-by:
-
Noralf Trønnes authored
This means that tinydrm_spi_bpw_supported() can be removed. Reviewed-by:
-
Noralf Trønnes authored
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers. Use the new SPI connector type instead. X server will now list the connector as Unknown instead of Virtual: X.Org X Server 1.19.2 Release Date: 2017-03-02 <...> [ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor section [ 53523.908] (II) modeset(0): EDID for output Unknown19-1 [ 53523.910] (II) modeset(0): Printing probed modes for output Unknown19-1 [ 53523.911] (II) modeset(0): Modeline "320x240"x0.0 0.00 320 320 320 320 240 240 240 240 (0.0 kHz eP) [ 53523.911] (II) modeset(0): Output Unknown19-1 connected [ 53523.912] (II) modeset(0): Using exact sizes for initial modes [ 53523.912] (II) modeset(0): Output Unknown19-1 using initial mode 320x240 +0+0 I won't chase down and fix userspace, but the new connector type will trickle out to userspace eventually. v2: Split patch in core and driver changes, expand commit message (Daniel) Cc: David Lechner <david@lechnology.com> Reviewed-by:
-
Noralf Trønnes authored
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers. Add a SPI connector type to match the actual connector. X will list the connector as Unknown: X.Org X Server 1.19.2 Release Date: 2017-03-02 <...> [ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor section [ 53523.908] (II) modeset(0): EDID for output Unknown19-1 [ 53523.910] (II) modeset(0): Printing probed modes for output Unknown19-1 [ 53523.911] (II) modeset(0): Modeline "320x240"x0.0 0.00 320 320 320 320 240 240 240 240 (0.0 kHz eP) [ 53523.911] (II) modeset(0): Output Unknown19-1 connected [ 53523.912] (II) modeset(0): Using exact sizes for initial modes [ 53523.912] (II) modeset(0): Output Unknown19-1 using initial mode 320x240 +0+0 The weston source shows that it will be listed as UNNAMED. v2: Split patch in core and driver changes, expand commit message (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
