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
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:
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.
> > > >
> > > >
> 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
> 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
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
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
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
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
---
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
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
> ---
>
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
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
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
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.
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
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
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
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
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
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 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
---
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
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
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
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
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
> ---
>
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:
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
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
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
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
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
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
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
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
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
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
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:
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
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
>
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
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
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
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
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
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
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
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
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
---
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
---
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
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
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
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
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
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 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,
>
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
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
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
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
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
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
>
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 be configured through
> > > > the generic
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 series ASAP and I'll rebase on top of
> that.
Hello Dan Carpenter.
Thanks for the report.
On 4/13/22 13:11, Dan Carpenter wrote:
Hello Thomas Hellström,
The patch 3bf3710e3718: "drm/ttm: Add a generic TTM memcpy move for
page-based iomem" from Jun 2, 2021, leads to the following Smatch
static checker warning:
On Wed, Apr 13, 2022 at 07:57:17AM +0200, Christoph Hellwig wrote:
> > - extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
> > + extern int vfio_pin_pages(struct vfio_device *vdev, unsigned long
> > *user_pfn,
> > int npage, int prot,
On Wed, Apr 13, 2022 at 07:55:24AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 12, 2022 at 12:53:28PM -0300, Jason Gunthorpe wrote:
> > All callers have a struct vfio_device trivially available, pass it in
> > directly and avoid calling the expensive vfio_group_get_from_dev().
>
> Instead of
On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar wrote:
>
> Hi Daniel
>
> On 4/8/2022 9:04 PM, Abhinav Kumar wrote:
> >
> >
> > On 4/7/2022 4:12 PM, Rob Clark wrote:
> >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar
> >> wrote:
> >>>
> >>> Hi Rob and Daniel
> >>>
> >>> On 4/7/2022 3:51 PM, Rob Clark
Hello Thomas Hellström,
The patch 3bf3710e3718: "drm/ttm: Add a generic TTM memcpy move for
page-based iomem" from Jun 2, 2021, leads to the following Smatch
static checker warning:
./include/drm/ttm/ttm_bo_driver.h:259 ttm_bo_move_sync_cleanup()
error: NULL dereference inside
Hello Andy,
On 4/13/22 12:46, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 06:27:28PM +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
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 platform device, the workaround is no longer
> needed. Remove it. Effectively reverts
Hi
Am 13.04.22 um 12:45 schrieb Javier Martinez Canillas:
Hello Thomas,
Thanks for working on this.
On 4/13/22 11:24, 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
On Tue, Apr 12, 2022 at 06:27:28PM +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
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 be configured through
> > > the generic functions and through a custom structure
> > > added to the generic union.
Hello Thomas,
Thanks for working on this.
On 4/13/22 11:24, 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
1 - 100 of 151 matches
Mail list logo
