Hello I got new report from dept, related to seqlock.
I applied dept 1.20 series on v5.18-rc7.
Below is what DEPT reported.
I think this is bogus because reader of p->alloc_lock cannot block
its writer. Or please kindly tell me if I'm missing something ;)
Thanks.
[8.032674]
The pull request you sent on Sat, 21 May 2022 06:24:38 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-05-21
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/93413c849f1fd2ad294320c6eb140b95bf153b8a
Thank you!
--
Deet-doot-dot, I am a bot.
https://bugzilla.kernel.org/show_bug.cgi?id=215618
Aurorans Solis (primaluc...@gmail.com) changed:
What|Removed |Added
CC|
On Wed, May 04, 2022 at 05:17:30PM +0900, Byungchul Park wrote:
> CURRENT STATUS
> +/*
[...]
> + * Ensure it has been called on ON/OFF transition.
> + */
> +void dept_enirq_transition(unsigned long ip)
> +{
> + struct dept_task *dt = dept_task();
> + unsigned long flags;
> +
> + if
On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote:
> to build without PCI to see what happens.
If you bring any of the "heuristic" and palette support code in, you
need PCI. I don't see any reason to take it out.
> Those old Macs use BootX, right? BootX is not supported ATM, as I don't
On Thu, 2022-05-19 at 09:11 +0200, Geert Uytterhoeven wrote:
> Hi Michal,
>
>
>
> On Wed, May 18, 2022 at 8:54 PM Michal Suchánek
> wrote:
>
> > On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote:
> > > --- a/drivers/gpu/drm/tiny/Kconfig
> > > +++ b/drivers/gpu/drm/tiny/Kconfig
Hi Neal,
I love your patch! Perhaps something to improve:
[auto build test WARNING on usb/usb-testing]
[also build test WARNING on robh/for-next v5.18-rc7 next-20220520]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
Hi,
On Mon, May 16, 2022 at 3:28 AM Thomas Zimmermann wrote:
>
> Hi Douglas,
>
> I understand that you're trying to tell userspace that the modelist has
> been made up, but it's not something that should be done via fragile
> heuristics IMHO.
>
> I looked at the Chromium source code that you
Xe_HP has enough fundamental differences from previous platforms that it
makes sense to use a separate SSEU init function to keep things
straightforward and easy to understand. We'll also add a has_xehp_dss
flag to the SSEU structure that will be used by other upcoming changes.
v2:
- Add
Storing the EU mask internally in the same format the I915_QUERY
topology queries use makes the final copy_to_user() a bit simpler, but
makes the rest of the driver's SSEU more complicated and harder to
follow. Let's switch to an internal representation that's more natural:
Xe_HP platforms will
This series reworks i915's internal handling of slice/subslice/EU (SSEU)
data to represent platforms like Xe_HP in a more natural manner and to
prepare for future platforms where the masks will need to grow in size.
One key idea of this series is that although we have a fixed ABI to
convey SSEU
PVC splits the mask of enabled DSS over two registers. It also changes
the meaning of the EU fuse register such that each bit represents a
single EU rather than a pair of EUs.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c
Although gen11 and gen12 architectures supported the concept of multiple
slices, in practice all the platforms that were actually designed only
had a single slice (i.e., note the parameters to 'intel_sseu_set_info'
that we pass for each platform). We can simplify the code slightly by
dropping the
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose
Slice/subslice/EU information should be obtained via the topology
queries provided by the I915_QUERY interface; let's turn off support for
the old GETPARAM lookups on Xe_HP and beyond where we can't return
meaningful values.
The slice mask lookup is meaningless since Xe_HP doesn't support
On 5/17/22 10:23, Hans de Goede wrote:
On x86/ACPI boards the acpi_video driver will usually initializing before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
---
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related
Quoting Kuogee Hsieh (2022-05-20 13:40:55)
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
If the DMA mask is not set explicitly, the following warning occurs
when the userspace tries to access the dma-buf via the CPU as
reported by syzbot here:
WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188
__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Modules linked in:
CPU: 0 PID:
On 2022-05-16 19:14, Alex Sierra wrote:
The intention is to test hmm device coherent type under different get
user pages paths. Also, test gup with FOLL_LONGTERM flag set in
device coherent pages. These pages should get migrated back to system
memory.
Signed-off-by: Alex Sierra
Reviewed-by:
On Fri, May 20, 2022 at 10:15:32AM +0100, Tvrtko Ursulin wrote:
>
> On 17/05/2022 04:20, Matt Roper wrote:
> > Slice/subslice/EU information should be obtained via the topology
> > queries provided by the I915_QUERY interface; let's turn off support for
> > the old GETPARAM lookups on Xe_HP and
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
---
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related
Hi,
On Tue, May 10, 2022 at 5:22 PM Dmitry Baryshkov
wrote:
>
> On Tue, 10 May 2022 at 22:30, Douglas Anderson wrote:
> >
> > This adds a devm managed version of drm_bridge_add(). Like other
> > "devm" function listed in drm_bridge.h, this function takes an
> > explicit "dev" to use for the
Hi,
On Tue, May 10, 2022 at 12:30 PM Douglas Anderson wrote:
>
> While working on the DP AUX bus code I found a few small things that
> should be fixed. Namely the non-devm version of
> of_dp_aux_populate_ep_devices() was missing an export. There was also
> an extra blank line in a kerneldoc and
Hi,
Am 11.04.22 um 13:00 schrieb Stefan Wahren:
Hi Maxime,
Am 11.04.22 um 09:35 schrieb Maxime Ripard:
Hi Stefan,
On Sun, Apr 10, 2022 at 02:32:02AM +0200, Stefan Wahren wrote:
Am 09.04.22 um 21:25 schrieb Stefan Wahren:
Hi,
today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected
Hi Linus,
Few final fixes for 5.18, one amdgpu, core dp mst leak fix, dma-buf
two fixes, and i915 has a few fixes, one for a regression on older
GM45 chipsets,
Regards,
Dave.
drm-fixes-2022-05-21:
drm fixes for 5.18 final
dma-buf:
- ioctl userspace use fix
- fix dma-buf sysfs name generation
Quoting Kuogee Hsieh (2022-05-20 13:06:05)
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
Quoting Kuogee Hsieh (2022-05-17 09:21:34)
> dp_catalog_ctrl_reset() will software reset DP controller. But it will
> not reset programmable registers to default value. DP driver still have
> to clear mask bits to interrupt status registers to disable interrupts
> after software reset of
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
---
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related
On Fri 20 May 09:26 PDT 2022, Kuogee Hsieh wrote:
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
---
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related
On Fri, May 20, 2022 at 12:20 AM Saurabh Sengar
wrote:
>
> There were two different approaches getting used in this driver to
> allocate vram:
> 1. VRAM allocation from PCI region for Gen1
> 2. VRAM alloaction from MMIO region for Gen2
> First approach limilts the vram to PCI BAR
On Fri, May 20, 2022 at 12:20:40AM -0700, Saurabh Sengar wrote:
> There were two different approaches getting used in this driver to
> allocate vram:
> 1. VRAM allocation from PCI region for Gen1
> 2. VRAM alloaction from MMIO region for Gen2
> First approach limilts the vram to PCI
On Fri, 20 May 2022 at 18:21, Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() before enable regulator at
> eDP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git
On Fri, 20 May 2022 at 18:09, Kuogee Hsieh wrote:
>
>
> On 5/19/2022 5:19 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-05-19 16:11:40)
> >> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
> >> b/drivers/phy/qualcomm/phy-qcom-edp.c
> >> index cacd32f..78b7306 100644
> >> ---
On 5/20/22 4:16 AM, Javier Martinez Canillas wrote:
The SPI core always reports a "MODALIAS=spi:", even if the device was
registered via OF. This means that the st7735r.ko module won't autoload if
a DT has a node with a compatible "okaya,rh128128t" string.
In that case, kmod expects a
Hi,
On Thu, May 19, 2022 at 5:34 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2022-05-12 16:24:13)
> > On Wed, May 11, 2022 at 6:58 PM Stephen Boyd wrote:
> > > Quoting Douglas Anderson (2022-04-18 10:17:54)
> > > > diff --git a/include/drm/dp/drm_dp_helper.h
> > > >
On Thu, May 19, 2022 at 04:14:11PM -0500, Rob Herring wrote:
> Now that the schema tools can extract type information for all
> properties (in order to decode dtb files), finding properties missing
> any type definition is fairly trivial though not yet automated.
>
> Fix the various property
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
---
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related
Hi,
On 4/26/22 19:55, Ville Syrjälä wrote:
> On Tue, Apr 26, 2022 at 11:35:02AM +0300, Pekka Paalanen wrote:
>> Hi all,
>>
>> I'm working on setting HDR & WCG video modes in Weston, and I thought
>> setting "max bpc" KMS property on the connector would be a good idea.
>> I'm confused about how it
On 5/19/2022 5:19 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-05-19 16:11:40)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index cacd32f..78b7306 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@
On 5/20/22 05:53, Geert Uytterhoeven wrote:
With sparse ("make C=2"), lots of
error: return expression in void function
messages are seen.
Fix this by removing the return statements to propagate void return
values.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Guenter Roeck
---
On Fri, May 20, 2022 at 02:15:43PM +0200, Marek Vasut wrote:
> The Refclk may be supplied by SoC clock output instead of crystal
> oscillator, make sure the clock are enabled before any other action
> is performed with the bridge chip, otherwise it may either fail to
> operate at all, or miss
With sparse ("make C=2"), lots of
error: return expression in void function
messages are seen.
Fix this by removing the return statements to propagate void return
values.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
On Fri, May 20, 2022 at 2:40 PM Geert Uytterhoeven wrote:
> On Thu, May 19, 2022 at 8:48 AM Guenter Roeck wrote:
> > On 5/18/22 17:55, kernel test robot wrote:
> > > tree/branch:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > branch HEAD:
Hi Günter
On Thu, May 19, 2022 at 8:48 AM Guenter Roeck wrote:
> On 5/18/22 17:55, kernel test robot wrote:
> > tree/branch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next
> > specific
The Refclk may be supplied by SoC clock output instead of crystal
oscillator, make sure the clock are enabled before any other action
is performed with the bridge chip, otherwise it may either fail to
operate at all, or miss reset GPIO toggle.
Reviewed-by: Lucas Stach
Fixes: 7caff0fc4296e
Hi Javier,
CC spi
On Fri, May 20, 2022 at 11:16 AM Javier Martinez Canillas
wrote:
> The SPI core always reports a "MODALIAS=spi:", even if the device was
> registered via OF. This means that the st7735r.ko module won't autoload if
> a DT has a node with a compatible "okaya,rh128128t" string.
>
On Fri, May 20, 2022 at 6:12 AM Sascha Hauer wrote:
>
> Hi Maya,
>
> On Fri, May 20, 2022 at 12:02:33PM +0200, Maya Matuszczyk wrote:
> > Hello,
> >
> > wt., 17 maj 2022 o 20:28 Heiko Stuebner napisał(a):
> > >
> > > Am Freitag, 22. April 2022, 09:28:17 CEST schrieb Sascha Hauer:
> > > > It's
Hi all,
This is for Tvrtko to pull to cross-merge sync drm-intel-next to
drm-intel-gt-next.
Dave, Daniel, IIUC this is what you prefer over having topic branches
for all the small things that are needed between drm-intel branches. I
don't think we've done this direct cross-merge before, so
Hi Maya,
On Fri, May 20, 2022 at 12:02:33PM +0200, Maya Matuszczyk wrote:
> Hello,
>
> wt., 17 maj 2022 o 20:28 Heiko Stuebner napisał(a):
> >
> > Am Freitag, 22. April 2022, 09:28:17 CEST schrieb Sascha Hauer:
> > > It's v11 time. There's only one small change to v10. Discussion seems to
> > >
On 17/05/2022 16:15, Matt Roper wrote:
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed
Hi Yuji,
On 5/20/22 11:48, yuji2.ishik...@toshiba.co.jp wrote:
> Hi Hans,
>
> Thank you for your comment.
> I agree that this submission lacks documents sharing basic idea of the
> accelerators; what do they accept and what do they yield.
> Where can I put a new document? Can I put it as a
Hi Hans,
Thank you for your comment.
I agree that this submission lacks documents sharing basic idea of the
accelerators; what do they accept and what do they yield.
Where can I put a new document? Can I put it as a comment in a source? Can I
add a file under Documentation/misc-devices
On 17/05/2022 04:20, Matt Roper wrote:
Storing the EU mask internally in the same format the I915_QUERY
topology queries use makes the final copy_to_user() a bit simpler, but
makes the rest of the driver's SSEU more complicated and harder to
follow. Let's switch to an internal representation
On 17/05/2022 04:20, Matt Roper wrote:
Although gen11 and gen12 architectures supported the concept of multiple
slices, in practice all the platforms that were actually designed only
had a single slice (i.e., note the parameters to 'intel_sseu_set_info'
that we pass for each platform). We can
The SPI core always reports a "MODALIAS=spi:", even if the device was
registered via OF. This means that the st7735r.ko module won't autoload if
a DT has a node with a compatible "okaya,rh128128t" string.
In that case, kmod expects a "MODALIAS=of:N*T*Cokaya,rh128128t" uevent but
instead will get
On 17/05/2022 04:20, Matt Roper wrote:
Slice/subslice/EU information should be obtained via the topology
queries provided by the I915_QUERY interface; let's turn off support for
the old GETPARAM lookups on Xe_HP and beyond where we can't return
meaningful values.
The slice mask lookup is
On Thu, May 19, 2022 at 02:29:12PM +0200, Marek Vasut wrote:
> The Refclk may be supplied by SoC clock output instead of crystal
> oscillator, make sure the clock are enabled before any other action
> is performed with the bridge chip, otherwise it may either fail to
> operate at all, or miss
On Mon, May 16, 2022 at 10:00:07AM -0400, Demi Marie Obenour wrote:
> On Mon, May 16, 2022 at 08:48:17AM +0200, Juergen Gross wrote:
> > On 14.05.22 17:55, Demi Marie Obenour wrote:
> > > In https://github.com/QubesOS/qubes-issues/issues/7481, a user reported
> > > that Xorg locked up when
On Wed, May 11, 2022 at 07:04:51PM +0900, Hyeonggon Yoo wrote:
> On Wed, May 11, 2022 at 08:39:29AM +0900, Byungchul Park wrote:
> > On Tue, May 10, 2022 at 08:18:12PM +0900, Hyeonggon Yoo wrote:
> > > On Mon, May 09, 2022 at 09:16:37AM +0900, Byungchul Park wrote:
> > > > CASE 1.
> > > >
> > > >
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Thursday, May 19, 2022 11:57 PM
> To: Neal Liu
> Cc: Rob Herring ; Krzysztof Kozlowski
> ; Joel Stanley ; Andrew
> Jeffery ; Felipe Balbi ; Sumit Semwal
> ; Christian König ;
> Geert Uytterhoeven ; Li Yang ;
>
On Mon, May 16, 2022 at 08:48:17AM +0200, Juergen Gross wrote:
> On 14.05.22 17:55, Demi Marie Obenour wrote:
> > In https://github.com/QubesOS/qubes-issues/issues/7481, a user reported
> > that Xorg locked up when resizing a VM window. While I do not have the
> > same hardware the user does and
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Thursday, May 19, 2022 11:56 PM
> To: Neal Liu
> Cc: Rob Herring ; Krzysztof Kozlowski
> ; Joel Stanley ; Andrew
> Jeffery ; Felipe Balbi ; Sumit Semwal
> ; Christian König ;
> Geert Uytterhoeven ; Li Yang ;
>
2022-05-19 at 23:14, Rob Herring wrote:
> Now that the schema tools can extract type information for all
> properties (in order to decode dtb files), finding properties missing
> any type definition is fairly trivial though not yet automated.
>
> Fix the various property schemas which are
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Friday, May 20, 2022 1:44 PM
> To: Neal Liu
> Cc: Rob Herring ; Krzysztof Kozlowski
> ; Joel Stanley ; Andrew
> Jeffery ; Felipe Balbi ; Sumit Semwal
> ; Christian König ;
> Geert Uytterhoeven ; Li Yang ;
>
On 19/05/2022 18:29, Chris Morgan wrote:
> From: Chris Morgan
>
> The Geekworm MZP280 panel is a 480x640 (portrait) panel with a
> capacitive touch interface and a 40 pin header meant to interface
> directly with the Raspberry Pi. The screen is 2.8 inches diagonally,
> and there appear to be at
Hello,
On Tue, May 17, 2022 at 04:30:29PM -0700, T.J. Mercier wrote:
> Thanks for your suggestion. This almost works. "dmabuf" as a key could
> work, but I'd actually like to account for each heap. Since heaps can
> be dynamically added, I can't accommodate every potential heap name by
>
On 19/05/2022 18:29, Chris Morgan wrote:
> From: Chris Morgan
>
> Add vendor prefix for Geekworm (https://geekworm.com).
>
> Signed-off-by: Chris Morgan
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Hi Dave, Daniel,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2022-05-20:
Fix for a memory leak in dp_mst, a (userspace) build fix for
DMA_BUF_SET_NAME defines and a directory name generation fix for dmabuf
stats
The following changes since commit
There were two different approaches getting used in this driver to
allocate vram:
1. VRAM allocation from PCI region for Gen1
2. VRAM alloaction from MMIO region for Gen2
First approach limilts the vram to PCI BAR size, which is 64 MB in most
legacy systems. This limits the maximum
Am 19.05.22 um 15:36 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, May 19, 2022 5:55 AM
To: intel-...@lists.freedesktop.org
Cc: matthew.william.a...@gmail.com; Christian König
; dri-devel@lists.freedesktop.org
Subject: [PATCH
Am 19.05.22 um 15:19 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, May 19, 2022 5:55 AM
To: intel-...@lists.freedesktop.org
Cc: matthew.william.a...@gmail.com; Christian König
; dri-devel@lists.freedesktop.org
Subject: [PATCH
Am 19.05.22 um 12:50 schrieb Matthew Auld:
On Thu, 19 May 2022 at 10:55, Christian König
wrote:
Just sending that out once more to intel-gfx to let the CI systems take
a look.
If all went well it should normally appear at [1][2], if CI was able
to pick up the series.
Since it's not currently
Am 20.05.22 um 00:58 schrieb T.J. Mercier:
[SNIP]
Is there some other
solution to the problem of exports getting blocked that you would
suggest here?
Well pretty much the same as Greg outlined as well. Go back to your
drawing board and come back with a solution which does not need such
If the DMA mask is not set explicitly, the following warning occurs
when the userspace tries to access the dma-buf via the CPU as
reported by syzbot here:
WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188
__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Modules linked in:
CPU: 0 PID:
Am 19.05.22 um 23:40 schrieb Kalesh Singh:
Processes can pin shared memory by keeping a handle to it through a
file descriptor; for instance dmabufs, memfd, and ashsmem (in Android).
In the case of a memory leak, to identify the process pinning the
memory, userspace needs to:
- Iterate the
Hello Thomas,
On 5/18/22 20:30, Thomas Zimmermann wrote:
>
> +config DRM_OFDRM
> + tristate "Open Firmware display driver"
> + depends on DRM && MMU && PPC
Shouldn't depend on OF? I mean, is a DRM driver for Open Firmware after all :)
I know that the old drivers/video/fbdev/offb.c
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 21498d01d045c5b95b93e0a0625ae965b4330ebe Add linux-next specific
files for 20220519
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com
On Thu, May 19, 2022 at 08:25:01PM +0300, Uri Arev wrote:
> This simple patch fixes a checkpatch.pl warning in `fbtft/fbtft-core.c`.
>
> Reported by Checkpatch:
> WARNING: struct fb_ops should normally be const
>
> Signed-off-by: Uri Arev
> ---
> drivers/staging/fbtft/fbtft-core.c | 4 ++--
>
95 matches
Mail list logo
