i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
either a MIPI DSI display or a LVDS display. The PHY mode is controlled
by SCU firmware and the driver would call a SCU firmware function to
configure the PHY mode. The single LVDS PHY has 4 data lanes to support
a LVDS display
Add support for Mixel MIPI DPHY + LVDS PHY combo IP
as found on Freescale i.MX8qxp SoC.
Cc: Guido Günther
Cc: Kishon Vijay Abraham I
Cc: Vinod Koul
Cc: Rob Herring
Cc: NXP Linux Team
Reviewed-by: Rob Herring
Reviewed-by: Guido Günther
Signed-off-by: Liu Ying
---
v6->v7:
* No change.
v5->v
This patch converts the mixel,mipi-dsi-phy binding to
DT schema format using json-schema.
Comparing to the plain text version, the new binding adds
the 'assigned-clocks', 'assigned-clock-parents' and
'assigned-clock-rates' properites, otherwise 'make dtbs_check'
would complain that there are mis-m
This patch allows LVDS PHYs to be configured through
the generic functions and through a custom structure
added to the generic union.
The parameters added here are based on common LVDS PHY
implementation practices. The set of parameters
should cover all potential users.
Cc: Kishon Vijay Abraham
The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
works with a Mixel MIPI DPHY + LVDS PHY combo to support either
a MIPI DSI display or a LVDS display. So, this patch calls
phy_set_mode() from nwl_dsi_mode_set() to set PHY mode to MIPI DPHY
explicitly.
Cc: Guido Günther
Cc: Rober
Hi,
This is the v7 series to add i.MX8qxp LVDS PHY mode support for the Mixel
PHY in the Freescale i.MX8qxp SoC.
The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp
SCU firmware. The PHY driver would call
On 2022-04-13 at 04:18:52 +0530, Vinay Belgaumkar wrote:
> This will ensure we don't have false positives when we run
> error injection tests.
>
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 42 ++---
> 1 file changed, 21 insertions(+), 2
On Thu, 2022-04-14 at 11:07 +0530, Vinod Koul wrote:
> On 13-04-22, 20:39, Liu Ying wrote:
> > On Wed, 2022-04-13 at 16:19 +0530, Vinod Koul wrote:
> > > On 13-04-22, 18:04, Liu Ying wrote:
> > > > Hi Vinod,
> > > >
> > > > On Wed, 2022-04-13 at 11:41 +0530, Vinod Koul wrote:
> > > > > On 02-04-22
Le 14/04/22 à 08:31, Lisovskiy, Stanislav a écrit :
On Wed, Apr 13, 2022 at 08:12:20PM +0300, Jani Nikula wrote:
On Wed, 13 Apr 2022, François Valenduc wrote:
Commit 15512021eb3975a8c2366e3883337e252bb0eee5
(15512021eb3975a8c2366e3883337e252bb0eee5) causes a lof of white spots
to appears on th
Am 14.04.22 um 01:47 schrieb Stephen Rothwell:
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/radeon/radeon_sync.c
between commit:
022074918042 ("drm/radeon: fix logic inversion in radeon_sync_resv")
from the drm-misc-fixes tree and commit:
On Wed, Apr 13, 2022 at 08:12:20PM +0300, Jani Nikula wrote:
> On Wed, 13 Apr 2022, François Valenduc wrote:
> > Commit 15512021eb3975a8c2366e3883337e252bb0eee5
> > (15512021eb3975a8c2366e3883337e252bb0eee5) causes a lof of white spots
> > to appears on the right upper corner of all console scre
Am 13.04.22 um 18:14 schrieb Michel Dänzer:
From: Michel Dänzer
Fixes compile errors with out-of-tree builds, e.g.
../drivers/gpu/drm/radeon/r420.c:38:10: fatal error: r420_reg_safe.h: No such
file or directory
38 | #include "r420_reg_safe.h"
| ^
Well st
The bug is here:
bus_flags = connector->display_info.bus_flags;
The list iterator 'connector-' will point to a bogus position containing
HEAD if the list is empty or no element is found. This case must
be checked before any use of the iterator, otherwise it will lead
to a invalid memory ac
On 13-04-22, 20:39, Liu Ying wrote:
> On Wed, 2022-04-13 at 16:19 +0530, Vinod Koul wrote:
> > On 13-04-22, 18:04, Liu Ying wrote:
> > > Hi Vinod,
> > >
> > > On Wed, 2022-04-13 at 11:41 +0530, Vinod Koul wrote:
> > > > On 02-04-22, 13:24, Liu Ying wrote:
> > > > > This patch allows LVDS PHYs to b
Hi Dave, Daniel,
Fixes for 5.18.
The following changes since commit 88711fa9a14f6f473f4a7645155ca51386e36c21:
Merge tag 'drm-misc-fixes-2022-04-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2022-04-08 09:22:16
+1000)
are available in the Git repository at:
https://git
On Wed, Apr 13, 2022 at 04:28:51PM +0200, Robert Foss wrote:
> On Sat, 9 Apr 2022 at 06:47, Xin Ji wrote:
> >
> > On Mon, Apr 04, 2022 at 12:52:14PM -0500, Rob Herring wrote:
> > > On Mon, Mar 28, 2022 at 08:09:54PM +0800, Xin Ji wrote:
> > > > Change bus-type define for DPI.
> > > >
> > > > Fixes
> From: Wang, Zhi A
> Sent: Thursday, April 14, 2022 5:09 AM
>
> > Or is it that only the page table levels themselves are GFNs and the
> > actual DMA's are IOVA? The unclear mixing of GFN as IOVA in the code
> > makes it inscrutible.
> >
>
> No. Even the HW is capable of controlling the level o
> From: Jason Gunthorpe
> Sent: Thursday, April 14, 2022 7:12 AM
>
> On Wed, Apr 13, 2022 at 09:08:40PM +, Wang, Zhi A wrote:
> > On 4/13/22 8:04 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
> > >> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> >
The subject is still misleading. It is fixing something. It may be
enhancing it as well but it is clearly fixing it first.
Quoting Kuogee Hsieh (2022-04-06 14:28:13)
> dp_hpd_plug_handle() is responsible for setting up main link and send
> uevent to notify user space framework to start video strea
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/radeon/radeon_sync.c
between commit:
022074918042 ("drm/radeon: fix logic inversion in radeon_sync_resv")
from the drm-misc-fixes tree and commit:
7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4"
On 14/04/2022 00:04, Kuogee Hsieh wrote:
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_
On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Thanks so much for the efforts. I prepared a branch which contains all our
> patches.The aim of the branch is for the VFIO maintainers to pull the whole
> bunch easily after the drm-intel-next got merged through drm (as
Quoting Kuogee Hsieh (2022-04-13 14:04:25)
> Current DP driver implementation, event thread is kept running
> after DP display is unbind. This patch fix this problem by disabling
> DP irq and stop event thread to exit gracefully at dp_display_unbind().
>
> Changes in v2:
> -- start event thread at
https://bugzilla.kernel.org/show_bug.cgi?id=215618
Pierre Choffet (ct@peuc.net) changed:
What|Removed |Added
CC||ct@peuc.net
--- Co
Hi folks:
Thanks so much for the efforts. I prepared a branch which contains all our
patches.The aim of the branch is for the VFIO maintainers to pull the whole
bunch easily after the drm-intel-next got merged through drm (as one of the
MMIO patches depends on a patch in drm-intel-next).
I dro
On Wed, Apr 13, 2022 at 09:08:40PM +, Wang, Zhi A wrote:
> On 4/13/22 8:04 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
> >> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> >>> On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
>
On Mon, 11 Apr 2022 11:58:43 +0800, Rex-BC Chen wrote:
> Disp_aal of MT8192 and MT8195 are fully compatible with disp_aal of
> MT8183. Therefore, we move the them to item "mediatek,mt8183-disp-aal".
>
> Signed-off-by: Rex-BC Chen
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml
On Mon, 11 Apr 2022 11:58:41 +0800, Rex-BC Chen wrote:
> The driver data of MT8183 and MT8173 are different.
>
> For MT8173, the gamma module is inside disp_aal. When we need to adjust
> gamma value, we need to use "has_gamma" to control gamma function
> inside disp_aal to adjust the gamma value.
On 11/04/2022 19:37, Vinod Polimera wrote:
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and
On 11/04/2022 19:37, Vinod Polimera wrote:
Check if the dpu format is supported or not using dpu_find_format.
Co-developed-by: Kalyan Thota
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h | 22 +
On 4/11/22 16:46, Robin Murphy wrote:
> Refactor the confusing logic to make it both clearer and more robust. If
> the host1x parent device does have an IOMMU domain then iommu_present()
> is redundantly true, while otherwise for the 32-bit DMA mask case it
> still doesn't say whether the IOMMU dri
Currently, 3-window mode causes some artifacting. Until the cause is
determined, provide an option to use direct mode instead. Direct mode
does the waveform lookups in software, so it has much higher CPU usage.
This limits the frame rate below the panel's ideal 85 Hz, so it leads to
slightly lower
The PineNote contains an eInk ED103TC2 panel connected to the EBC,
powered by a TI TPS651851 PMIC.
Signed-off-by: Samuel Holland
---
.../boot/dts/rockchip/rk3566-pinenote.dtsi| 80 +++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinenot
The RK356x SoCs contain an EBC. Add its node.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 7cdef800cb3c..5
ED103TC2 is a 10.3" 1872x1404 eInk panel which supports up to 16 levels
of grayscale and an 85 Hz frame rate. The timings and polarities here
were taken from the manufacturer's datasheet.
Since this panel is an electrophoretic display (EPD), the color depth is
independent from the bus width. Inste
Several areas of the display can be refreshed concurrently, but only if
they do not overlap. This commit adds a queue of damaged areas, and
schedules them for refresh based on collision with other areas. While
the queue is unbounded, there is logic to quickly drop duplicate areas.
Because three-wi
The global refresh mode is used to initialize and clear the screen.
It is the most efficient refresh mode. It uses two pixel buffers (old
and new) and a frame count. The frame count is set to the number of
phases in the waveform. The hardware then looks up the combination of
(old pixel value, new p
Some panels, like the one in the PineNote, are reflected. Since the
driver already has to copy pixels, the driver can handle this with
little additional overhead.
Currently, there is no devicetree binding for this situation, so control
the behavior via a module parameter.
Signed-off-by: Samuel Ho
EPDs require some additional timing data beyond what is normally
provided by drm_display_mode, as that struct is designed for CRTs/LCDs.
For example, EPDs care about the width and position of the gate driver
(vertical) clock pulse within a line.
EPDs also update some number of pixels in parallel,
Some waveforms, such as GC16, cause the display to flash even when the
previous and next pixel values are the same. This can be helpful,
because it produces more consistent brightness, but usually it is more
distracting. Add an option, enabled by default, for the hardware to
ignore the LUT and alwa
EPD refreshes are extremely slow; they take anywhere between hundreds of
milliseconds and several seconds. To avoid blocking userspace, perform
these refreshes on a separate thread. The thread will also take care of
initializing the display before first use and clearing it when the CRTC
is disabled
This commit adds the "context" structure which holds all buffers needed
to refresh the display. It is allocated separately from the CRTC state
because it is reused as long as no mode change occurs.
There are three buffers holding Y4 (grayscale 4 bits/pixel) pixel data:
- "prev" - contents of the
The EBC contains a 16 KiB SRAM which stores the current LUT. It needs to
be programmed any time the LUT changes or the hardware block is enabled.
Since both of these triggers can happen at the same time, use a flag to
avoid writing the LUT twice.
Signed-off-by: Samuel Holland
---
drivers/gpu/dr
The Rockchip E-Book Controller (EBC) is a timing controller (TCON)
responsible for sending timing signals and pixel update waveforms to an
electrophoretic display (EPD). The EBC has several modes of operation.
In direct mode, it reads precomputed source driver polarity data from a
series of buffers
The Rockchip E-Book Controller (EBC) has a relatively simple and self-
contained display pipeline. The pipeline consists of a single CRTC,
encoder, and bridge, with the bridge normally attached to a panel.
Initially, there is also a single plane. Since all blitting is done in
software, the driver
Currently, this library is focused on LUTs and LUT files, specifically
the PVI wbf-format files shipped with E-Ink displays. It provides
helpers to load and validate LUT files, and extract LUTs from them.
Since EPD controllers need the LUTs in various formats, this library
allows drivers to declar
The Rockchip E-Book Controller (EBC) is a controller for Electrophoretic
Displays (EPDs). It is self-contained; it does not interact directly
with the VOP or the RGA.
While two of the regulator consumers here actually power the display
panel, not the EBC hardware, they are consumed here because th
This series adds a DRM driver for the electrophoretic display controller
found in a few different Rockchip SoCs, specifically the RK3566/RK3568
variant[0] used by the PineNote tablet[1].
This is my first real involvement with the DRM subsystem, so please let
me know where I am misunderstanding thi
Looks good to me, series is:
Reviewed-by: Francisco Jerez
Matt Roper writes:
> This structure has a great comment describing the fields, but it's not
> currently in kerneldoc form and does not show up in the generated
> documentation. Let's fix that and also clarify the description of what
>
On Sat, 09 Apr 2022 17:11:53 +0800, xinlei@mediatek.com wrote:
> From: Xinlei Lee
>
> Add dt-binding documentation of dsi for MediaTek MT8186 SoC.
>
> Signed-off-by: Xinlei Lee
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: Rex-BC Chen
> ---
> .../devicetree/bindings/display
On Sat, Apr 09, 2022 at 05:11:52PM +0800, xinlei@mediatek.com wrote:
> From: Xinlei Lee
>
> Convert mediatek,dsi.txt to mediatek,dsi.yaml format
>
> Signed-off-by: Xinlei Lee
> ---
> .../display/mediatek/mediatek,dsi.txt | 62 -
> .../display/mediatek/mediatek,dsi.yaml
On 4/13/22 8:04 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
>> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
>>> On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
>
Current DP driver implementation, event thread is kept running
after DP display is unbind. This patch fix this problem by disabling
DP irq and stop event thread to exit gracefully at dp_display_unbind().
Changes in v2:
-- start event thread at dp_display_bind()
Fixes: e91e3065a806 ("drm/msm/dp: A
On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
> >> On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
> >>> Yeah, I was thinking about that too, but on th
On Wed, 13 Apr 2022 14:14:42 -0400
Alex Deucher wrote:
> On Wed, Apr 13, 2022 at 1:33 PM Michele Ballabio
> wrote:
> >
> > On Mon, 11 Apr 2022 14:34:37 -0400
> > Alex Deucher wrote:
> >
> > > On Sat, Apr 9, 2022 at 12:28 PM Michele Ballabio
> > > wrote:
> > > >
> > > > On Tue, 5 Apr 2022 1
On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
>> On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
>>> Yeah, I was thinking about that too, but on the other hand I think it
>>> is completely wrong that gvt requires kvm
eOn Wed, Apr 13, 2022 at 1:46 PM Rob Herring wrote:
>
> On Wed, Apr 13, 2022 at 12:58 PM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 13.04.22 um 14:51 schrieb Rob Herring:
> > > On Wed, Apr 13, 2022 at 4:24 AM Thomas Zimmermann
> > > wrote:
> > >>
> > >> Create a platform device for each
On Wed, Apr 13, 2022 at 12:58 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.04.22 um 14:51 schrieb Rob Herring:
> > On Wed, Apr 13, 2022 at 4:24 AM Thomas Zimmermann
> > wrote:
> >>
> >> Create a platform device for each OF-declared framebuffer and have
> >> offb bind to these devices. Allows for
Le mercredi 13 avril 2022 à 09:57 +0200, AngeloGioacchino Del Regno a écrit :
> Il 13/04/22 09:03, allen-kh.cheng ha scritto:
> > Hi Nicolas,
> >
> > On Tue, 2022-04-12 at 10:48 -0400, Nicolas Dufresne wrote:
> > > Le lundi 11 avril 2022 à 11:41 +0800, yunfei.d...@mediatek.com a
> > > écrit :
> >
On Wed, Apr 13, 2022 at 1:33 PM Michele Ballabio wrote:
>
> On Mon, 11 Apr 2022 14:34:37 -0400
> Alex Deucher wrote:
>
> > On Sat, Apr 9, 2022 at 12:28 PM Michele Ballabio
> > wrote:
> > >
> > > On Tue, 5 Apr 2022 10:23:16 -0400
> > > Alex Deucher wrote:
> > >
> > > > On Mon, Apr 4, 2022 at 3:3
Hi
Am 13.04.22 um 18:05 schrieb Daniel Vetter:
On Wed, Apr 13, 2022 at 12:50:50PM +0200, Javier Martinez Canillas wrote:
On 4/13/22 11:24, Thomas Zimmermann wrote:
A workaround makes fbdev hot-unplugging work for framebuffers without
device. The only user for this feature was offb. As each OF
On 4/13/22 19:58, Thomas Zimmermann wrote:
> Hi
[snip]
>>>
>>> /* Populate everything else. */
>>> of_platform_default_populate(NULL, NULL, NULL);
>>
>> I'm pretty sure it's just this call that's the problem for PPC though
>> none of the above existed when adding this caused a r
Hi
Am 13.04.22 um 14:51 schrieb Rob Herring:
On Wed, Apr 13, 2022 at 4:24 AM Thomas Zimmermann wrote:
Create a platform device for each OF-declared framebuffer and have
offb bind to these devices. Allows for real hot-unplugging and other
drivers besides offb.
Originally, offb created framebu
Hi Rob,
On Wed, Apr 13, 2022 at 09:00:15AM -0500, Rob Herring wrote:
> It's not good practice to define multiple types for the same property, so
> factor out the type reference making the properties always an uint32-array
> with a length of 1 or 3 items.
>
> Signed-off-by: Rob Herring
Looks goo
On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
> > Yeah, I was thinking about that too, but on the other hand I think it
> > is completely wrong that gvt requires kvm at all. A vfio_device is not
> > supposed to
On Mon, 11 Apr 2022 14:34:37 -0400
Alex Deucher wrote:
> On Sat, Apr 9, 2022 at 12:28 PM Michele Ballabio
> wrote:
> >
> > On Tue, 5 Apr 2022 10:23:16 -0400
> > Alex Deucher wrote:
> >
> > > On Mon, Apr 4, 2022 at 3:39 PM Michele Ballabio
> > > wrote:
> > > >
> > > > On Mon, 4 Apr 2022 13:
Hi Dave & Daniel,
A few fixes for v5.18.
The following changes since commit 05afd57f4d34602a652fdaf58e0a2756b3c20fd4:
drm/msm/gpu: Fix crash on devices without devfreq support (v2)
(2022-03-08 13:55:23 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.gi
On Mon, 11 Apr 2022, François Valenduc wrote:
> Commit 15512021eb3975a8c2366e3883337e252bb0eee5
> (15512021eb3975a8c2366e3883337e252bb0eee5) causes a lof of white spots
> to appears on the right upper corner of all console screens see the
> attached photo). git-bisect shows that this is the off
On Wed, 13 Apr 2022, Cong Liu wrote:
> this function has been deleted since commit 9bdb073464d6 ("drm/i915/gvt:
> Change KVMGT as self load module"), remove the deprecated function
> declaration.
I don't want to push this right now avoid conflicts in other pending
work. Cc'd Zhi & Zhenyu to pick
On Wed, 13 Apr 2022, François Valenduc wrote:
> Commit 15512021eb3975a8c2366e3883337e252bb0eee5
> (15512021eb3975a8c2366e3883337e252bb0eee5) causes a lof of white spots
> to appears on the right upper corner of all console screens (see
> https://drive.google.com/file/d/13GabEvOIKSAj5yox6ybAZEDu
On 4/13/22 19:02, Andy Shevchenko wrote:
> On Wed, Apr 13, 2022 at 06:23:57PM +0200, Javier Martinez Canillas wrote:
>> These are declared in the ssd130x-i2c transport driver but the information
>> is not I2C specific, and could be used by other SSD130x transport drivers.
>>
>> Move them to the ssd
On Wed, Apr 13, 2022 at 06:23:57PM +0200, Javier Martinez Canillas wrote:
> These are declared in the ssd130x-i2c transport driver but the information
> is not I2C specific, and could be used by other SSD130x transport drivers.
>
> Move them to the ssd130x core driver and just set the OF device en
Hello,
This series adds a ssd130x-spi driver that provides a 4-wire SPI transport
support for SSD130x OLED controllers that can be accessed over a SPI bus.
The driver is quite similar to existing ssd130x-i2c driver that is used by
I2C controllers, but there is a difference in the protocol used by
These are declared in the ssd130x-i2c transport driver but the information
is not I2C specific, and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to
an ID that could be used to lookup the correct device info from an array.
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over SPI.
There is a difference in the communication protocol when using 4-wire SPI
instead of I2C. For the latter, a control byte that contains a D/C# field
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the properties and examples for OLED devices under SPI.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v4:
- Add a description for the dc-gp
The current compatible strings for SSD130x I2C controllers contain an "fb"
and "-i2c" suffixes. These have been deprecated and more correct ones were
added, that don't encode a subsystem or bus used to interface the devices.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-b
The current compatible strings for SSD130x I2C controllers contain both an
"fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
and also that are for devices that can be accessed over an I2C bus.
But a DT is supposed to describe the hardware and not Linux implementation
detai
Hi All,
As discussed in the "[RFC] drm/kms: control display brightness through
drm_connector properties" thread, step 1 of the plan is to stop
registering multiple /sys/class/backlight devs for a single display.
On x86 there can be multiple firmware + direct-hw-access methods
for controlling the
On Wed, Apr 13, 2022 at 06:06:01PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 13, 2022 at 08:39:52AM -0300, Jason Gunthorpe wrote:
> > I already looked into that for a while, it is a real mess too because
> > of how the notifiers are used by the current drivers, eg gvt assumes
> > the notifier i
From: Michel Dänzer
Fixes compile errors with out-of-tree builds, e.g.
../drivers/gpu/drm/radeon/r420.c:38:10: fatal error: r420_reg_safe.h: No such
file or directory
38 | #include "r420_reg_safe.h"
| ^
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon
From: Michel Dänzer
Instead of relying on it getting pulled in indirectly.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/tiny/bochs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index ed971c8bb446..4f8bf86633df 100644
--- a
On Wed, Apr 13, 2022 at 12:50:50PM +0200, Javier Martinez Canillas wrote:
> On 4/13/22 11:24, Thomas Zimmermann wrote:
> > A workaround makes fbdev hot-unplugging work for framebuffers without
> > device. The only user for this feature was offb. As each OF framebuffer
> > now has an associated plat
On Wed, 13 Apr 2022, Christoph Hellwig wrote:
> On Wed, Apr 13, 2022 at 01:47:05PM +, Wang, Zhi A wrote:
>> > the GVT code in the i915 is a bit of a mess right now due to strange
>> > abstractions and lots of indirect calls. This series refactors various
>> > bits to clean that up. The main
Hi Dave & Daniel -
The first drm/i915 pull for v5.19.
BR,
Jani.
drm-intel-next-2022-04-13-1:
drm/i915 feature pull for v5.19:
Features and functionality:
- Add support for new Tile 4 format on DG2 (Stan)
- Add support for new CCS clear color compression on DG2 (Mika, Juha-Pekka)
- Add suppor
Hi Richard,
On Tue, Apr 12, 2022 at 04:50:00PM -0500, Richard Gong wrote:
> Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> There are some AMD GFX cards (such as WX3200 and RX640) that won't work
> with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards
On Wed, Apr 13, 2022 at 11:25:02AM +0200, Daniel Vetter wrote:
> On Wed, Apr 13, 2022 at 10:21:28AM +0200, Daniel Vetter wrote:
> > I messed up the delayed takover path in the locking conversion in
> > 6e7da3af008b ("fbcon: Move console_lock for register/unlink/unregister").
> >
> > Fix it by re-e
On Wed, Apr 13, 2022 at 02:26:23PM +, Wang, Zhi A wrote:
> On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote:
> >
> >> It seems Jani's makefile clean patch has already included this one, I can
> >> just simply drop this one so that Chris
On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote:
>
>> It seems Jani's makefile clean patch has already included this one, I can
>> just simply drop this one so that Christoph won't need to re-send everything.
>>
>> For the branch to move on,
On Sat, 9 Apr 2022 at 06:47, Xin Ji wrote:
>
> On Mon, Apr 04, 2022 at 12:52:14PM -0500, Rob Herring wrote:
> > On Mon, Mar 28, 2022 at 08:09:54PM +0800, Xin Ji wrote:
> > > Change bus-type define for DPI.
> > >
> > > Fixes: a43661e7e819 ("dt-bindings:drm/bridge:anx7625:add vendor define")
> > >
>
On Wed, Apr 13, 2022 at 08:11:05AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 12, 2022 at 12:53:36PM -0300, Jason Gunthorpe wrote:
> > + if (WARN_ON(!READ_ONCE(vdev->open_count)))
> > + return -EINVAL;
>
> I think all the WARN_ON()s in this patch need to be WARN_ON_ONCE,
> otherwise
It's not good practice to define multiple types for the same property, so
factor out the type reference making the properties always an uint32-array
with a length of 1 or 3 items.
Signed-off-by: Rob Herring
---
.../bindings/display/panel/panel-timing.yaml | 42 ---
1 file change
On 4/11/22 2:13 PM, Christoph Hellwig wrote:
> Hi all,
>
> the GVT code in the i915 is a bit of a mess right now due to strange
> abstractions and lots of indirect calls. This series refactors various
> bits to clean that up. The main user visible change is that almost all
> of the GVT code move
On Wed, Apr 13, 2022 at 01:39:35PM +, Wang, Zhi A wrote:
> It seems Jani's makefile clean patch has already included this one, I can
> just simply drop this one so that Christoph won't need to re-send everything.
>
> For the branch to move on, I am merging the patches and will re-generate the
On Wed, Apr 13, 2022 at 08:01:10AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 12, 2022 at 12:53:31PM -0300, Jason Gunthorpe wrote:
> > Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> > reason to use a group interface here, kvmgt has easy access to a
> > vfio_device.
On 4/13/22 12:33 PM, Jani Nikula wrote:
> On Mon, 11 Apr 2022, Christoph Hellwig wrote:
>> On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
Up to you but I usually sort these lists
>>>
>>> Yeah, please do. Otherwise matches what I sent, so ack.
>>
>> Let's just merge your 2 patch
On Wed, Apr 13, 2022 at 08:00:08AM +0200, Christoph Hellwig wrote:
> This looks good execept the extern nitpick:
>
> Reviewed-by: Christoph Hellwig
>
> However I'd move this before the previous patch. More of the explanation
> there.
Yes, that looks good, done
Thanks,
Jason
[Public]
> On Wed, Apr 13, 2022 at 3:43 AM Paul Menzel
> wrote:
> >
> > Dear Richard,
> >
> >
> > Thank you for sending out v4.
> >
> > Am 12.04.22 um 23:50 schrieb Richard Gong:
> > > Active State Power Management (ASPM) feature is enabled since kernel
> 5.14.
> > > There are some AMD GFX card
On Wed, Apr 13, 2022 at 3:43 AM Paul Menzel wrote:
>
> Dear Richard,
>
>
> Thank you for sending out v4.
>
> Am 12.04.22 um 23:50 schrieb Richard Gong:
> > Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> > There are some AMD GFX cards (such as WX3200 and RX640) that wo
On Wed, Apr 13, 2022 at 4:24 AM Thomas Zimmermann wrote:
>
> Create a platform device for each OF-declared framebuffer and have
> offb bind to these devices. Allows for real hot-unplugging and other
> drivers besides offb.
>
> Originally, offb created framebuffer devices while initializing its
> m
1 - 100 of 160 matches
Mail list logo
