https://bugzilla.kernel.org/show_bug.cgi?id=216224
--- Comment #3 from happysmas...@protonmail.com ---
Created attachment 301377
--> https://bugzilla.kernel.org/attachment.cgi?id=301377&action=edit
GPU crash 2022-05-24
Was most likely from lolMiner and on kernel 5.17.4, as I upgraded to 5.18.0
https://bugzilla.kernel.org/show_bug.cgi?id=216224
--- Comment #2 from happysmas...@protonmail.com ---
Created attachment 301376
--> https://bugzilla.kernel.org/attachment.cgi?id=301376&action=edit
SteamVR-induced crash 2022-05-26
--
You may reply to this email to add a comment.
You are recei
https://bugzilla.kernel.org/show_bug.cgi?id=216224
--- Comment #1 from happysmas...@protonmail.com ---
Created attachment 301375
--> https://bugzilla.kernel.org/attachment.cgi?id=301375&action=edit
SteamVR-induced crash 2022-06-18
--
You may reply to this email to add a comment.
You are recei
https://bugzilla.kernel.org/show_bug.cgi?id=216224
happysmas...@protonmail.com changed:
What|Removed |Added
Attachment #301374|SteamTV-induced crash |SteamVR-induced crash
https://bugzilla.kernel.org/show_bug.cgi?id=216224
Bug ID: 216224
Summary: AMDGPU fails to reset RX 480 after Ring GFX timeout
Product: Drivers
Version: 2.5
Kernel Version: 5.18.0 and earlier versions
Hardware: Intel
OS: Li
When prepare-slumber hfi fails, we should follow a6xx_gmu_force_off()
sequence.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/driver
We can do a few more things to improve our chance at a successful gpu
recovery, especially during a hangcheck timeout:
1. Halt CP and GMU core
2. Do RBBM GBIF HALT sequence
3. Do a soft reset of GPU core
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx.xm
Update gpu register array with gpucc memory region.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dts
To improve our chance of a successful recovery, we should ensure that
cx headswitch collapses. Cx headswitch might be kept enabled through a
vote from another driver like iommu or even another hardware subsystem.
So, poll the cx gdscr register to ensure that it collapses during
recovery.
Signed-of
There are some hardware logic under CX domain. For a successful
recovery, we should ensure cx headswitch collapses to ensure all the
stale states are cleard out. This is especially true to for a6xx family
where we can GMU co-processor.
Currently, cx doesn't collapse due to a devlink between gpu an
In the scenario where there is one a single submit which is hung, gpu is
power collapsed when it is retired. Because of this, by the time we call
reover(), gpu state would be already clear. Fix this by correctly
managing the pm runtime votes.
Signed-off-by: Akhil P Oommen
---
(no changes since v
We already enable gpu power from msm_gpu_submit(), so avoid a duplicate
pm_runtime_get/put from msm_job_run().
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/msm_ringbuffer.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.
Recently, I debugged a few device crashes which occured during recovery
after a hangcheck timeout. It looks like there are a few things we can
do to improve our chance at a successful gpu recovery.
First one is to ensure that CX GDSC collapses which clears the internal
states in gpu's CX domain.
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 36d2ac0e15af4dfb942279e8097ab831661859e6
commit: cf07f850c0483b3314eb69fd8c810e461cef4035 [3/8] Merge remote-tracking
branch 'drm/drm-next' into drm-tip
config: ia64-allmodconfig
(https://download.01.org/0day-ci/archive/20220709/20
On 7/8/22 03:15, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20220707:
>
on uml/x86_64:
WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
Depends on [n]: VT [=n] && FB [=y] && !UML [=y]
Selected by [y]:
- DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM_KMS_HE
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 36d2ac0e15af4dfb942279e8097ab831661859e6
commit: cf07f850c0483b3314eb69fd8c810e461cef4035 [3/8] Merge remote-tracking
branch 'drm/drm-next' into drm-tip
config: microblaze-randconfig-r011-20220707
(https://download.01.org/0day-ci/a
Update debug print to report bridge timings over connector ones.
Drop missed comment commit from mxsfb.
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc
Drop unneeded headers, sort rest alphabetically, no functional change.
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Lucas Stach
Cc:
Drop the crtc_ prefix from mode, consistently use the plain one.
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Liu Ying
Cc: Lucas Stach
Cc: Marek
The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".
Switch to the new function and reduce boilerplate.
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vas
On 7/8/2022 4:48 PM, Daniele Ceraolo Spurio wrote:
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not ex
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return v
A PFN is not secure enough to promise that the memory is not IO. And
direct access via memcpy() that only handles CPU memory will crash on
S390 if the PFN is an IO PFN, as we have to use the memcpy_to/fromio()
that uses the special S390 IO access instructions. On the other hand,
a "struct page *" i
Following the updated vfio_pin/unpin_pages(), use the simpler "iova".
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Tested-by: Terrence Xu
Tested-by: Eric Farman
Signed-off-by: Nicolin Chen
---
drivers/vfio/vfio.c | 6 +++---
include/linux/vfio.h | 2 +
The vfio_ap_ops code maintains both nib address and its PFN, which
is redundant, merely because vfio_pin/unpin_pages API wanted pfn.
Since vfio_pin/unpin_pages() now accept "iova", change "saved_pfn"
to "saved_iova" and remove pfn in the vfio_ap_validate_nib().
Reviewed-by: Jason Gunthorpe
Tested
There's only one caller that checks its return value with a WARN_ON_ONCE,
while all other callers don't check the return value at all. Above that,
an undo function should not fail. So, simplify the API to return void by
embedding similar WARN_ONs.
Also for users to pinpoint which condition fails,
The vfio_ccw_cp code maintains both iova and its PFN list because the
vfio_pin/unpin_pages API wanted pfn list. Since vfio_pin/unpin_pages()
now accept "iova", change to maintain only pa_iova list and rename all
"pfn_array" strings to "page_array", so as to simplify the code.
Reviewed-by: Jason Gu
The vfio_pin/unpin_pages() so far accepted arrays of PFNs of user IOVA.
Among all three callers, there was only one caller possibly passing in
a non-contiguous PFN list, which is now ensured to have contiguous PFN
inputs too.
Pass in the starting address with "iova" alone to simplify things, so
ca
This driver is the only caller of vfio_pin/unpin_pages that might pass
in a non-contiguous PFN list, but in many cases it has a contiguous PFN
list to process. So letting VFIO API handle a non-contiguous PFN list
is actually counterproductive.
Add a pair of simple loops to pass in contiguous PFNs
The ap_aqic() is called by vfio_ap_irq_enable() where it passes in a
virt value that's casted from a physical address "h_nib". Inside the
ap_aqic(), it does virt_to_phys() again.
Since ap_aqic() needs a physical address, let's just pass in a pa of
ind directly. So change the "ind" to "pa_ind".
Re
It's a bit redundant for the maths here using roundup.
Suggested-by: Jason Gunthorpe
Tested-by: Terrence Xu
Signed-off-by: Nicolin Chen
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu
This is a preparatory series for IOMMUFD v2 patches. It prepares for
replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
with IOMMUFD version.
There's a gap between these two versions: the vfio_iommu_type1 version
inputs a non-contiguous PFN list and outputs another PFN list for t
The test needs GT reset to trigger the scrubbing logic, so we can only
run it when reset is enabled.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i9
On Fri, 08 Jul 2022 00:31:56 +0300, Dmitry Baryshkov wrote:
> The p1 region was probably added by mistake, none of the DTS files
> provides one (and the driver source code also doesn't use one). Drop it
> now.
>
> Fixes: 687825c402f1 ("dt-bindings: msm/dp: Change reg definition")
> Signed-off-by:
On 2022-07-08 07:28, David Hildenbrand wrote:
On 07.07.22 21:03, Alex Sierra wrote:
[WHY]
Have a cleaner way to expose all page zone helpers in one header
What exactly is a "page zone"? Do you mean a buddy zone as in
include/linux/mmzone.h ?
Zone as in ZONE_DEVICE. Maybe we could extend mmzone
On 7/8/2022 1:58 PM, Dmitry Baryshkov wrote:
On Fri, 8 Jul 2022 at 22:42, Abhinav Kumar wrote:
On 7/8/2022 9:00 AM, Abhinav Kumar wrote:
On 7/8/2022 8:25 AM, Doug Anderson wrote:
Hi,
On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
Set the panel orientation in drm when the pane
On Fri, 8 Jul 2022 at 22:42, Abhinav Kumar wrote:
>
>
>
> On 7/8/2022 9:00 AM, Abhinav Kumar wrote:
> >
> >
> > On 7/8/2022 8:25 AM, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
> >>>
> >>> Set the panel orientation in drm when the panel is directly
- Use DEFINE_SIMPLE_DEV_PM_OPS() instead of the SIMPLE_DEV_PM_OPS()
macro. This makes it possible to remove the __maybe_unused flags on
the callback functions.
- Since we only have callbacks for suspend/resume, we can conditionally
compile the dev_pm_ops structure for when CONFIG_PM_SLEEP is
Instead of building the IPU driver code into the ingenic-drm driver,
create a ingenic-ipu driver.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/Kconfig | 2 +-
drivers/gpu/drm/ingenic/Makefile | 2 +-
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 33 +---
Avoid requesting a full modeset if the sharpness property is not
modified, because then we don't actually need it.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c
Add support for the JZ4760 and JZ4760B SoCs to the ingenic-drm display
driver.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/inge
The previous "GPL v2" string is deprecated. For more info, see commit
bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
Add compatible strings for the LCD controllers found in the JZ4760 and
JZ4760B SoCs from Ingenic.
Signed-off-by: Paul Cercueil
Cc: Rob Herring
Cc: Krzysztof Kozlowski
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/display/ingenic,lcd.yaml | 2 ++
1 file changed, 2 inserti
Hi,
A small set of changes to the ingenic-drm driver.
The most notable thing is that ingenic-ipu is now its own platform
driver.
Cheers,
-Paul
Paul Cercueil (6):
dt-bindings/display: ingenic: Add compatible string for the JZ4760(B)
drm/ingenic: Fix MODULE_LICENSE() string
drm/ingenic: Add
From: Arthur Grillo
Considering the current adoption of the KUnit framework, convert the
DRM mm selftest to the KUnit API.
Signed-off-by: Arthur Grillo
Tested-by: David Gow
Acked-by: Daniel Latypov
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maíra Canal
---
Documentation/gpu/todo.
Considering the current adoption of the KUnit framework, convert the
DRM buddy selftest to the KUnit API.
Tested-by: David Gow
Acked-by: Daniel Latypov
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/selftests/Makefile| 2 +-
.../gpu/drm/self
Considering the current adoption of the KUnit framework, convert the
DRM DP MST helper selftest to the KUnit API.
Co-developed-by: Rubens Gomes Neto
Signed-off-by: Rubens Gomes Neto
Tested-by: David Gow
Acked-by: Daniel Latypov
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maíra Canal
Considering the current adoption of the KUnit framework, convert the
DRM plane helper selftest to the KUnit API.
Co-developed-by: Djakson C. G. Filho
Signed-off-by: Djakson C. G. Filho
Co-developed-by: Anderson Fraga
Signed-off-by: Anderson Fraga
Tested-by: David Gow
Acked-by: Daniel Latypov
Considering the current adoption of the KUnit framework, convert the
DRM format selftest to the KUnit API.
Tested-by: David Gow
Acked-by: Daniel Latypov
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/sel
On Fri, Jul 08, 2022 at 04:30:32PM -0400, Eric Farman wrote:
> External email: Use caution opening links or attachments
>
>
> On Tue, 2022-07-05 at 23:27 -0700, Nicolin Chen wrote:
> > This is a preparatory series for IOMMUFD v2 patches. It prepares for
> > replacing vfio_iommu_type1 implementati
Considering the current adoption of the KUnit framework, convert the
DRM rect selftest to the KUnit API.
Co-developed-by: Carlos Veras
Signed-off-by: Carlos Veras
Co-developed-by: Matheus Vieira
Signed-off-by: Matheus Vieira
Tested-by: David Gow
Acked-by: Daniel Latypov
Reviewed-by: Javier M
Considering the current adoption of the KUnit framework, convert the
DRM cmdline parser selftest to the KUnit API.
Co-developed-by: Arthur Grillo
Signed-off-by: Arthur Grillo
Tested-by: David Gow
Acked-by: Daniel Latypov
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maíra Canal
---
d
Considering the current adoption of the KUnit framework, convert the
DRM damage helper selftest to the KUnit API.
Co-developed-by: Arthur Grillo
Signed-off-by: Arthur Grillo
Tested-by: David Gow
Acked-by: Daniel Latypov
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maíra Canal
---
dr
Hi everyone,
Here is the v5 of the conversion of selftests to KUnit. Since the v4, the only
fix was checking the checkpatch warnings and checks (Thank you Javier).
Thanks for your attention and any feedback is welcomed!
Best Regards,
- Maíra Canal
v1 -> v2:
https://lore.kernel.org/dri-devel/20
On Tue, 2022-07-05 at 23:27 -0700, Nicolin Chen wrote:
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
>
> There's a gap between these two versions: the vfio_iommu_type1
> version
On Tue, 2022-07-05 at 23:27 -0700, Nicolin Chen wrote:
> Most of the callers of vfio_pin_pages() want "struct page *" and the
> low-level mm code to pin pages returns a list of "struct page *" too.
> So there's no gain in converting "struct page *" to PFN in between.
>
> Replace the output paramet
On Tue, 2022-07-05 at 23:27 -0700, Nicolin Chen wrote:
> A PFN is not secure enough to promise that the memory is not IO. And
> direct access via memcpy() that only handles CPU memory will crash on
> S390 if the PFN is an IO PFN, as we have to use the
> memcpy_to/fromio()
> that uses the special S3
On Tue, 2022-07-05 at 23:27 -0700, Nicolin Chen wrote:
> The vfio_pin/unpin_pages() so far accepted arrays of PFNs of user
> IOVA.
> Among all three callers, there was only one caller possibly passing
> in
> a non-contiguous PFN list, which is now ensured to have contiguous
> PFN
> inputs too.
>
>
On Tue, 2022-07-05 at 23:27 -0700, Nicolin Chen wrote:
> The vfio_ccw_cp code maintains both iova and its PFN list because the
> vfio_pin/unpin_pages API wanted pfn list. Since
> vfio_pin/unpin_pages()
> now accept "iova", change to maintain only pa_iova list and rename
> all
> "pfn_array" strings
On Wed, 2022-07-06 at 14:05 -0300, Jason Gunthorpe wrote:
> On Tue, Jul 05, 2022 at 11:27:53PM -0700, Nicolin Chen wrote:
> > This driver is the only caller of vfio_pin/unpin_pages that might
> > pass
> > in a non-contiguous PFN list, but in many cases it has a contiguous
> > PFN
> > list to proces
On Tue, 2022-07-05 at 23:27 -0700, Nicolin Chen wrote:
> This driver is the only caller of vfio_pin/unpin_pages that might
> pass
> in a non-contiguous PFN list, but in many cases it has a contiguous
> PFN
> list to process. So letting VFIO API handle a non-contiguous PFN list
> is actually counter
On Fri, Jul 08, 2022 at 07:24:30AM +, Xu, Terrence wrote:
> External email: Use caution opening links or attachments
>
>
> > -Original Message-
> > From: intel-gvt-dev On Behalf
> > Of
> > On Thu, Jul 07, 2022 at 06:08:45AM +, Tian, Kevin wrote:
> >
> > > > Request for testing:
Hi Hans,
On Fri, Jul 8, 2022 at 9:46 PM Hans de Goede wrote:
> On 7/8/22 20:21, Geert Uytterhoeven wrote:
> > Extract the code to check for a named mode parameter into its own
> > function, to streamline the main parsing flow.
> >
> > Signed-off-by: Geert Uytterhoeven
> > --- a/drivers/gpu/drm/
Hi Hans,
On Fri, Jul 8, 2022 at 10:06 PM Geert Uytterhoeven wrote:
> On Fri, Jul 8, 2022 at 9:28 PM Hans de Goede wrote:
> > On 7/8/22 20:21, Geert Uytterhoeven wrote:
> > > If no mode name part was specified, mode_end is zero, and the "ret ==
> > > mode_end" check does the wrong thing.
> > >
>
Hi Hans.
On Fri, Jul 8, 2022 at 9:28 PM Hans de Goede wrote:
> On 7/8/22 20:21, Geert Uytterhoeven wrote:
> > If no mode name part was specified, mode_end is zero, and the "ret ==
> > mode_end" check does the wrong thing.
> >
> > Fix this by checking for a non-zero return value instead.
>
> Which
On 7/8/2022 12:51 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2022-07-08 12:38:09)
+ kuogee
On 7/8/2022 12:27 PM, Stephen Boyd wrote:
Yes I see the same address for P1 on sc7280. Maybe it's a typo? Abhinav,
can you confirm?
P1 block does exist on sc7280 and yes its address is same as
Quoting Abhinav Kumar (2022-07-08 12:38:09)
> + kuogee
>
> On 7/8/2022 12:27 PM, Stephen Boyd wrote:
> >
> > Yes I see the same address for P1 on sc7280. Maybe it's a typo? Abhinav,
> > can you confirm?
>
> P1 block does exist on sc7280 and yes its address is same as the address
> mentioned in sc71
On 7/8/2022 12:38 PM, Abhinav Kumar wrote:
+ kuogee
On 7/8/2022 12:27 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 20:46:43)
On 08/07/2022 04:28, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 14:31:56)
The p1 region was probably added by mistake, none of the DTS
Hi,
On 7/8/22 20:21, Geert Uytterhoeven wrote:
> Extract the code to check for a named mode parameter into its own
> function, to streamline the main parsing flow.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/drm_modes.c | 41 +++--
> 1 file chan
On 7/8/2022 9:00 AM, Abhinav Kumar wrote:
On 7/8/2022 8:25 AM, Doug Anderson wrote:
Hi,
On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
Set the panel orientation in drm when the panel is directly connected,
i.e. we're not using an external bridge. The external bridge case is
already
+ kuogee
On 7/8/2022 12:27 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 20:46:43)
On 08/07/2022 04:28, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 14:31:56)
The p1 region was probably added by mistake, none of the DTS files
provides one (and the driver source code
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them.
It is less verbose and it improves the semantic.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/vc4/vc4_validate_shaders.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_
Hi Geert,
On 7/8/22 20:21, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series contains fixes and improvements for specifying video
> modes on the kernel command line.
>
> This has been tested on ARAnyM using a work-in-progress Atari DRM driver
> (more info and related patches can be
Hi Geert,
On 7/8/22 20:21, Geert Uytterhoeven wrote:
> If no mode name part was specified, mode_end is zero, and the "ret ==
> mode_end" check does the wrong thing.
>
> Fix this by checking for a non-zero return value instead.
Which is wrong to do, since now if you have e.g. a mode list
with:
"
Quoting Dmitry Baryshkov (2022-07-07 20:46:43)
> On 08/07/2022 04:28, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2022-07-07 14:31:56)
> >> The p1 region was probably added by mistake, none of the DTS files
> >> provides one (and the driver source code also doesn't use one). Drop it
> >> now.
Quoting Dmitry Baryshkov (2022-07-07 20:59:02)
> On 08/07/2022 04:32, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2022-07-07 14:32:00)
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> b/Documentation/devicetree/bindings/display/msm/dp-controller.y
The pull request you sent on Fri, 8 Jul 2022 09:38:00 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/for-5.19/fbdev-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/086ff84617185393a0bbf25830c4f36412a7d3f4
Thank you!
--
Deet-d
It is fairly common for named video modes to contain dashes (e.g.
"tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names
are not recognized, as the dash is considered to be a separator between
mode name and vertical refrsh.
Fix this by skipping any dashes that are not followed immed
Add support for drawing the SMPTE and tiles test patterns in buffers
using big-endian formats.
For now this is limited to XRGB1555 and RGB565, which are the most
common big-endian formats.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
tests/util/pattern.c | 31 +
Add support for rendering the crosshairs in a buffer using the
big-endian RGB565 format.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
tests/util/pattern.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index 627f402be1d02e1c..1222b47ea3f
DRM formats are defined to be little-endian, unless the
DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel
values need to take endianness into account.
Introduce a swap32() helper to byteswap 32-bit values, and a
cpu_to_le32() helper to convert 32-bit values from CPU-endian to
li
Cairo always uses native byte order for rendering.
Hence if the byte order of the frame buffer differs from the byte order
of the CPU, the frame buffer contents need to be byteswapped twice: once
before rendering, to convert to native byte order, and a second time
after rendering, to restore the f
Add support for drawing the SMPTE pattern in buffers using a
color-indexed frame buffer formats with two, four, or sixteen colors.
Note that this still uses 256 as the CLUT size, as
DRM_IOCTL_MODE_SETGAMMA enforces that the size matches against the
(fixed) gamma size, while the CLUT size depends o
When specifying a frame buffer format like "RG16be" (big-endian RG16),
modetest still uses the little-endian variant, as the format string is
truncated to four characters.
Fix this by increasing the format string size to 7 bytes (6 characters +
NUL terminator).
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven
---
Any better suggestion than appending "be"?
v2:
- New.
---
tests/util/format.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/util/format.c b/tests/util/format.c
index a5464de6fc1ac70f..42a652c9a402a654 100644
--- a/tests/util/format.c
+++ b/t
Hi all,
This patch series fixes some endianness issues in libdrm.
It has been tested on ARAnyM using a work-in-progress Atari DRM driver.
Changes compared to v1:
- Consider arm, aarch64, microblaze, s390, and sh in endianness
checks,
- Add Acked-by,
- Add swap32() intermediate h
The color LUT for the SMPTE pattern in indexed mode contains 22 entries,
although only 13 are non-unique.
Reduce the size of the color LUT by dropping duplicate entries, so it
can be reused for formats supporting e.g. 16 colors. Rename
util_smpte_c8_gamma() to util_smpte_index_gamma() accordingly
- sparc64-linux-gnu-gcc does not define __BIG_ENDIAN__ or SPARC, but
does define __sparc__, hence replace the check for SPARC by a check
for __sparc__,
- powerpc{,64,64}-linux-gnu-gcc does not define __ppc__ or __ppc64__,
but does define __BIG_ENDIAN__.
powerpc64le-linux-gnu-gcc
DRM formats are defined to be little-endian, unless the
DRM_FORMAT_BIG_ENDIAN flag is set. Hence writes of multi-byte pixel
values need to take endianness into account.
Introduce a swap16() helper to byteswap 16-bit values, and a
cpu_to_le16() helper to convert 16-bit values from CPU-endian to
li
Big-endian fourcc values have the MSB set, as that is the
DRM_FORMAT_BIG_ENDIAN flag. Hence printing the last byte unmodified
leads to weird characters.
Fix this by stripping the DRM_FORMAT_BIG_ENDIAN flag, and appending "be"
for big-endian formats.
Sample impact:
Planes:
id crtc
Add support for drawing the SMPTE pattern in a buffer using the C2
indexed format.
As only four colors are available, resolution is halved, and the pattern
is drawn in a PenTile RG-GB matrix, using Floyd-Steinberg dithering.
The magnitude of the green subpixels is reduced, as there are twice as
ma
Add support for creating buffers using the new color-indexed frame
buffer formats with two, four, and sixteen colors.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Split off changes to tests/modetest/buffers.c.
---
tests/modetest/buffers.c | 15 +++
1 file changed, 15 insertions(+)
Store the number of available colors for color-indexed frame
buffer formats in the format_info[] array. This avoids the need of test
code for having to use switch statements all the time to obtain the
number of colors, or to check if a mode is color-indexed or not.
Signed-off-by: Geert Uytterhoev
Add support for drawing the SMPTE pattern in a buffer using the C1
indexed format.
As only two colors are available, the pattern is drawn in black and
white, using Floyd-Steinberg dithering.
Signed-off-by: Geert Uytterhoeven
---
v2:
New.
---
tests/util/pattern.c | 171
Add support for creating buffers using big-endian formats.
For now this is limited to XRGB1555 and RGB565, which are the most
common big-endian formats.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
tests/modetest/buffers.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/
Add support for drawing the SMPTE pattern in a buffer using the C4
indexed format.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Use new smpte_top[],
- Split off changes to tests/util/pattern.c.
---
tests/util/pattern.c | 42 ++
1 file changed, 42 insert
Add support for creating buffers using the new color-indexed frame
buffer formats with two, four, and sixteen colors.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Split off changes to tests/util/format.c.
---
tests/util/format.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/util/
Fill in the LSB when converting color components from 8-bit to 16-bit.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
tests/util/pattern.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index 178aee8341a38920..3753ebc
Introduce fourcc codes for color-indexed frame buffer formats with two,
four, and sixteen colors.
The fill order (the order in which multiple pixels are packed in a byte)
is the same order as used for indexed-color (2, 4, and 16 colors) images
in the PNG specification, Version 1.2.
This order is a
Hi all,
A long outstanding issue with the DRM subsystem has been the lack of
support for low-color displays, as used typically on older desktop
systems, and on small embedded displays.
This patch series adds support for color-indexed frame buffer formats
with 2, 4, and 16 colors. It has
1 - 100 of 302 matches
Mail list logo
