There is no need to call the DSSERR() function directly to print
a custom message when handling an error from platform_get_irq() function
as it is going to display an appropriate error message
in case of a failure.
Signed-off-by: Ruan Jinjie
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 1 -
Hi Dave,
On 2023/7/27 07:09, Dave Chinner wrote:
On Wed, Jul 26, 2023 at 05:14:09PM +0800, Qi Zheng wrote:
On 2023/7/26 16:08, Dave Chinner wrote:
On Mon, Jul 24, 2023 at 05:43:51PM +0800, Qi Zheng wrote:
@@ -122,6 +126,13 @@ void shrinker_free_non_registered(struct shrinker
*shrinker);
There is no need to call the DRM_DEV_ERROR() function directly to print
a custom message when handling an error from platform_get_irq() function
as it is going to display an appropriate error message
in case of a failure.
Signed-off-by: Ruan Jinjie
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c |
Fix the following make htmldocs errors/warnings:
./drivers/gpu/drm/i915/gt/uc/intel_huc.c:29: ERROR: Unexpected indentation.
./drivers/gpu/drm/i915/gt/uc/intel_huc.c:30: WARNING: Block quote ends without
a blank line; unexpected unindent.
./drivers/gpu/drm/i915/gt/uc/intel_huc.c:35: WARNING:
Hi--
On 7/26/23 18:19, David Reaver wrote:
> The struct sync_fence_info member num_fences was missing a colon in the
> kernel-doc, causing this warning when running make htmldocs:
>
> ./include/uapi/linux/sync_file.h:77: warning: Function parameter or member
> 'num_fences' not described in
The struct sync_fence_info member num_fences was missing a colon in the
kernel-doc, causing this warning when running make htmldocs:
./include/uapi/linux/sync_file.h:77: warning: Function parameter or member
'num_fences' not described in 'sync_file_info'
num_fences was also clearly missing from
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:622 amdgpu_gfx_enable_kcq() warn:
inconsistent indenting
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5992
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 3 +--
1 file changed, 1 insertion(+), 2
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
As the DPU driver has switched to fetching data from MDSS driver, we can
now drop the UBWC and highest_bank_bit parts of the DPU hw catalog.
Signed-off-by: Dmitry Baryshkov
---
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 6 --
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
Switch to using data from MDSS driver to program the SSPP fetch and UBWC
configuration.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 18 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 7
On 7/26/2023 3:58 PM, Dmitry Baryshkov wrote:
On Thu, 27 Jul 2023 at 01:30, Abhinav Kumar wrote:
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
As we are going to use MDSS data for DPU programming, populate missing
MDSS data. The UBWC 1.0 and no UBWC cases do not require MDSS
On Wed, Jul 26, 2023 at 05:14:09PM +0800, Qi Zheng wrote:
> On 2023/7/26 16:08, Dave Chinner wrote:
> > On Mon, Jul 24, 2023 at 05:43:51PM +0800, Qi Zheng wrote:
> > > @@ -122,6 +126,13 @@ void shrinker_free_non_registered(struct shrinker
> > > *shrinker);
> > > void shrinker_register(struct
On Thu, 27 Jul 2023 at 01:30, Abhinav Kumar wrote:
>
>
>
> On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
> > As we are going to use MDSS data for DPU programming, populate missing
> > MDSS data. The UBWC 1.0 and no UBWC cases do not require MDSS
> > programming, so skip them.
> >
>
> Can you pls
On Wed, Jul 26, 2023 at 3:33 PM Dmitry Baryshkov
wrote:
>
> On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
> >
> > On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On 26/07/2023 23:11, Rob Clark wrote:
> > > > On Wed, Jul 26, 2023 at 1:00 PM Dmitry Baryshkov
> > > >
On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
>
> On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
> wrote:
> >
> > On 26/07/2023 23:11, Rob Clark wrote:
> > > On Wed, Jul 26, 2023 at 1:00 PM Dmitry Baryshkov
> > > wrote:
> > >>
> > >> On Wed, 26 Jul 2023 at 21:28, Rob Clark wrote:
> > >>>
>
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
As we are going to use MDSS data for DPU programming, populate missing
MDSS data. The UBWC 1.0 and no UBWC cases do not require MDSS
programming, so skip them.
Can you pls point me to the downstream references you used for msm8998?
Was that
On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
wrote:
>
> On 26/07/2023 23:11, Rob Clark wrote:
> > On Wed, Jul 26, 2023 at 1:00 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On Wed, 26 Jul 2023 at 21:28, Rob Clark wrote:
> >>>
> >>> On Thu, Jul 13, 2023 at 1:26 PM Akhil P Oommen
> >>> wrote:
>
Using the `kunit_tool` with the command:
tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests/
Lead to this error[0]. Fix it by expliciting removing the
CONFIG_DRM_FBDEV_EMULATION.
[0]
ERROR:root:
WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
Depends on
On 7/20/2023 4:01 PM, Alan Previn wrote:
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915
On Sat, Jul 15, 2023 at 6:38 AM Konrad Dybcio wrote:
>
> On 7.07.2023 18:08, Rob Clark wrote:
> > On Thu, Jul 6, 2023 at 5:25 PM Konrad Dybcio
> > wrote:
> >>
> >> Apart from all these comments, I don't really see the point of this patch,
> >> other than trying to tie together Qualcomm's
On 27/07/2023 00:44, Rob Clark wrote:
On Wed, Jul 26, 2023 at 2:38 PM Dmitry Baryshkov
wrote:
On 27/07/2023 00:37, Rob Clark wrote:
On Thu, Jul 6, 2023 at 8:45 PM Dmitry Baryshkov
wrote:
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
/* Helper for formating the chip_id in
On Wed, Jul 26, 2023 at 2:38 PM Dmitry Baryshkov
wrote:
>
> On 27/07/2023 00:37, Rob Clark wrote:
> > On Thu, Jul 6, 2023 at 8:45 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On 07/07/2023 00:10, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>>/* Helper for formating the chip_id in the way
On 26/07/2023 23:11, Rob Clark wrote:
On Wed, Jul 26, 2023 at 1:00 PM Dmitry Baryshkov
wrote:
On Wed, 26 Jul 2023 at 21:28, Rob Clark wrote:
On Thu, Jul 13, 2023 at 1:26 PM Akhil P Oommen wrote:
On Fri, Jul 07, 2023 at 05:34:04AM +0300, Dmitry Baryshkov wrote:
On 07/07/2023 00:10, Rob
On 27/07/2023 00:37, Rob Clark wrote:
On Thu, Jul 6, 2023 at 8:45 PM Dmitry Baryshkov
wrote:
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
On Thu, Jul 6, 2023 at 8:45 PM Dmitry Baryshkov
wrote:
>
> On 07/07/2023 00:10, Rob Clark wrote:
> > From: Rob Clark
> >
> > Since the revision becomes an opaque identifier with future GPUs, move
> > away from treating different ranges of bits as having a given meaning.
> > This means that we
On Thu, 27 Jul 2023 at 00:21, Abhinav Kumar wrote:
>
>
>
> On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
> > DPU programming requires knowledge of some of UBWC parameters. This
> > results in duplication of UBWC data between MDSS and DPU drivers. Export
> > the required data from MDSS driver.
>
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
DPU programming requires knowledge of some of UBWC parameters. This
results in duplication of UBWC data between MDSS and DPU drivers. Export
the required data from MDSS driver.
Signed-off-by: Dmitry Baryshkov
---
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
Rename the ubwc_version field to ubwc_enc_version, it denotes the
version of the UBWC encoder, not the "UBWC version".
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 26 +-
1 file changed, 13
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 1 new issues were detected and 0 were fixed.
In total, 8 issues are still open and 30 have been
On Wed, Jul 26, 2023 at 1:00 PM Dmitry Baryshkov
wrote:
>
> On Wed, 26 Jul 2023 at 21:28, Rob Clark wrote:
> >
> > On Thu, Jul 13, 2023 at 1:26 PM Akhil P Oommen
> > wrote:
> > >
> > > On Fri, Jul 07, 2023 at 05:34:04AM +0300, Dmitry Baryshkov wrote:
> > > >
> > > > On 07/07/2023 00:10, Rob
On Wed, 26 Jul 2023 at 21:28, Rob Clark wrote:
>
> On Thu, Jul 13, 2023 at 1:26 PM Akhil P Oommen
> wrote:
> >
> > On Fri, Jul 07, 2023 at 05:34:04AM +0300, Dmitry Baryshkov wrote:
> > >
> > > On 07/07/2023 00:10, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > There are cases where
Add a check to mtk_drm_mode_fb_create() that rejects any modifier that
is not the AFBC mode supported by MT8195's display overlays.
Tested by booting ChromeOS and verifying the UI works, and by running
the ChromeOS kms_addfb_basic binary, which has a test called
"addfb25-bad-modifier" that
Hello,
On Wed, Jul 26, 2023 at 05:44:28PM +0100, Tvrtko Ursulin wrote:
...
> > So, yeah, if you want to add memory controls, we better think through how
> > the fd ownership migration should work.
>
> It would be quite easy to make the implicit migration fail - just the matter
> of failing the
> Would it make more sense to commmonize function
> mtk_plane_format_mod_supported()
> and call that one here instead?
I had considered that, but mtk_plane_format_mod_supported() is
required to take a drm_plane as a parameter in order to conform to the
type signature defined in drm_plane_funcs,
Hello,
On Wed, Jul 26, 2023 at 12:14:24PM +0200, Maarten Lankhorst wrote:
> > So, yeah, if you want to add memory controls, we better think through how
> > the fd ownership migration should work.
>
> I've taken a look at the series, since I have been working on cgroup memory
> eviction.
>
> The
From: Thierry Reding
panel-lvds alone is not a valid compatible string and we always need a
specific compatible string as well. Nexus 7 can come with one of (at
least) two panels, so pick one of them as the specific compatible
string.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
The Chunghwa CLAA070WP03XG is an LVDS panel, so move it to the correct
bindings file.
Signed-off-by: Thierry Reding
---
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 --
2 files
From: Thierry Reding
The Hydis HV070WX2-1E0 is a 7" WXGA (800x1280) TFT LCD LVDS panel that
is one of the variants used on Google Nexus 7.
Signed-off-by: Thierry Reding
---
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi Dave, Daniel,
Fixes for 6.5.
The following changes since commit 28801cc85906ea62043e62c71def7f9daaf1c168:
Merge tag 'amd-drm-fixes-6.5-2023-07-20' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-07-21 12:16:47
+1000)
are available in the Git repository at:
From: Thierry Reding
The LVDS bindings require a specific compatible string in addition to
the generic "panel-lvds". Add the HannStar HSD101PWW2 which is used on
a similar device (ASUS TF201) and seems to work fine with slightly
modified timings in DT.
Suggested-by: Svyatoslav Ryhel
From: Thierry Reding
The porch maximum values for the HannStar HSD101PWW2 are unusually
small. Make them a bit larger to allow a more flexibility when
overriding the timings in device tree. Unfortunately the datasheet
doesn't list porch limits in detail, so this is a bit of guesswork.
From: Thierry Reding
The HannStar HSD101PWW2 is an LVDS panel, so move it to the correct
bindings file.
Signed-off-by: Thierry Reding
---
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 --
2 files
On Thu, Jul 13, 2023 at 1:26 PM Akhil P Oommen wrote:
>
> On Fri, Jul 07, 2023 at 05:34:04AM +0300, Dmitry Baryshkov wrote:
> >
> > On 07/07/2023 00:10, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > There are cases where there are differences due to SoC integration.
> > > Such as
On Monday, July 24th, 2023 at 23:14, Michał Winiarski
wrote:
> Having a limit of 64 DRM devices is not good enough for modern world
> where we have multi-GPU servers, SR-IOV virtual functions and virtual
> devices used for testing.
> Let's utilize full minor range for DRM devices.
> To avoid
Hi
Am 26.07.23 um 09:57 schrieb Boris Brezillon:
On Tue, 25 Jul 2023 20:50:43 +0200
Thomas Zimmermann wrote:
Hi
Am 24.07.23 um 13:26 schrieb Boris Brezillon:
The dma-buf backend is supposed to provide its own vm_ops, but some
implementation just have nothing special to do and leave vm_ops
On 26/07/2023 17:46, Thomas Zimmermann wrote:
Hi
Am 26.07.23 um 10:41 schrieb Jocelyn Falempe:
On 13/07/2023 15:41, Jocelyn Falempe wrote:
Most aspeed devices have a BMC, which allows to remotely see the screen.
Also in the common use case, those servers don't have a display
connected.
So
On Jul 26 2023, Doug Anderson wrote:
> Hi,
>
> On Wed, Jul 26, 2023 at 1:57 AM Benjamin Tissoires wrote:
> >
> > > @@ -1143,7 +1208,14 @@ void i2c_hid_core_remove(struct i2c_client *client)
> > > struct i2c_hid *ihid = i2c_get_clientdata(client);
> > > struct hid_device *hid;
> > >
>
On 21/07/2023 23:21, Tejun Heo wrote:
On Wed, Jul 12, 2023 at 12:46:04PM +0100, Tvrtko Ursulin wrote:
$ cat drm.memory.stat
card0 region=system total=12898304 shared=0 active=0 resident=12111872
purgeable=167936
card0 region=stolen-system total=0 shared=0 active=0 resident=0
The variable i is being initialized with a value that is never read,
it is being re-assigned in the for-loop statement immediately afterwards.
Remove it.
Signed-off-by: Colin Ian King
---
drivers/char/agp/amd64-agp.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi,
On Wed, Jul 26, 2023 at 1:57 AM Benjamin Tissoires wrote:
>
> > @@ -1143,7 +1208,14 @@ void i2c_hid_core_remove(struct i2c_client *client)
> > struct i2c_hid *ihid = i2c_get_clientdata(client);
> > struct hid_device *hid;
> >
> > - i2c_hid_core_power_down(ihid);
> > + /*
Hi Javier
Am 25.07.23 um 21:53 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hi
[...]
Yes. I meant to move drivers/video/logo/ to drivers/fbdev/core/logo and to
source its Kconfig from drivers/fbdev/core/Kconfig, since it now depends
on FB_CORE.
No, please rather leave
Hi
Am 26.07.23 um 10:41 schrieb Jocelyn Falempe:
On 13/07/2023 15:41, Jocelyn Falempe wrote:
Most aspeed devices have a BMC, which allows to remotely see the screen.
Also in the common use case, those servers don't have a display
connected.
So add a Virtual connector, to reflect that even if
Hi
Am 25.07.23 um 23:31 schrieb Roger Sewell:
Thomas,
Thank you for your reply.
Table 10 in the following document says that 1440x900@60Hz is
supported:
https://www.intel.com/content/dam/support/us/en/documents/motherboards/server/s5520ur/sb/e44031012_s5520ur_s5520urt_tps_r1_9.pdf
That
Hi Jocelyn
Am 26.07.23 um 10:10 schrieb Jocelyn Falempe:
[...]
So the old kernel already did the right thing.
In the *new* code the nearest-named function I could see
issys/class/drm/card1-eDP-1/modes
mgag200_mode_config_mode_valid, which returns MODE_OK at the end of the
function if the
On Sun, 23 Jul 2023 18:08:42 +0200, Marijn Suijten wrote:
> Both SM6350 and SM6375 support only a single DSI link, and don't have a
> corresponding dsi1 node in DTS. Their examples should not suggest an
> output interface port on the display-controller node to this inexistant
> DSI host, with a
Hi
Am 26.07.23 um 12:11 schrieb Roger Sewell:
Jocelyn,
How can I check for sure whether I am using 24 or 32 bits per pixel
?
The easiest solution if you already rebuilt your kernel is to print
the variable bpp here:
Hi,
On Wed, Jul 26, 2023 at 5:41 AM Maxime Ripard wrote:
>
> Hi,
>
> On Tue, Jul 25, 2023 at 01:34:37PM -0700, Douglas Anderson wrote:
> > NOTE: arguably, the right thing to do here is actually to skip this
> > patch and simply remove all the extra checks from the individual
> > drivers. Perhaps
Hi Wang,
Thank you for the patch.
On Wed, Jul 26, 2023 at 07:57:56PM +0800, Wang Ming wrote:
> It is possible that dma_request_chan will return EPROBE_DEFER,
> which means that disp->dev is not ready yet. In this case,
> dev_err(disp->dev), there will be no output. This patch fixes the bug.
Javier Martinez Canillas writes:
> Drivers are not allowed to fail after drm_atomic_helper_swap_state() has
> been called and the new atomic state is stored into the current sw state.
>
> Since the struct ssd130x_device .data_array is allocated in the encoder's
> .atomic_enable callback, the
Geert Uytterhoeven writes:
> On Wed, Jul 26, 2023 at 12:55 PM Javier Martinez Canillas
> wrote:
>> There is only a single caller for both helper functions and these don't do
>> much other than allocate and free two buffers, so let's just inline them.
>>
>> Suggested-by: Geert Uytterhoeven
>>
Geert Uytterhoeven writes:
Hello Geert,
> Hi Maxime,
>
> On Wed, Jul 26, 2023 at 3:54 PM Maxime Ripard wrote:
>> On Wed, Jul 26, 2023 at 02:33:06PM +0200, Geert Uytterhoeven wrote:
>> > > >> Also, Javier pointed me to a discussion you had on IRC about using
>> > > >> devm
>> > > >> allocation
Maxime Ripard writes:
Hello Maxime,
> Hi,
>
> On Wed, Jul 26, 2023 at 01:52:37PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Jul 26, 2023 at 12:00 PM Maxime Ripard wrote:
>> > On Tue, Jul 25, 2023 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
[...]
>> The second buffer (containing the
Hi Maxime,
On Wed, Jul 26, 2023 at 3:54 PM Maxime Ripard wrote:
> On Wed, Jul 26, 2023 at 02:33:06PM +0200, Geert Uytterhoeven wrote:
> > > >> Also, Javier pointed me to a discussion you had on IRC about using devm
> > > >> allocation here. We can't really do that. KMS devices are only freed
> >
Pointer pexec is being assigned a value however it is never read. The
assignment is redundant and can be removed. Replace sizeof(*pexec)
with sizeof the type and remove the declaration of pointer pexec.
Signed-off-by: Colin Ian King
---
V2: completely remove the declaration of pexec and replace
On Wed, Jul 26, 2023 at 02:33:06PM +0200, Geert Uytterhoeven wrote:
> > >> Also, Javier pointed me to a discussion you had on IRC about using devm
> > >> allocation here. We can't really do that. KMS devices are only freed
> > >> once the last userspace application closes its fd to the device
On 26/07/2023 14:38, Pranjal Ramajor Asha Kanojiya wrote:
On 7/26/2023 8:30 AM, Jeffrey Hugo wrote:
On 7/25/2023 5:40 AM, Colin Ian King wrote:
Pointer pexec is being assigned a value however it is never read. The
assignment is redundant and can be removed.
Signed-off-by: Colin Ian King
On 26/07/2023 15:27, Amit Pundir wrote:
> Adding a reserved memory region for the framebuffer memory
> (the splash memory region set up by the bootloader).
>
> It fixes a kernel panic (arm-smmu: Unhandled context fault
> at this particular memory region) reported on DB845c running
> v5.10.y.
>
>
Hi,
On Wed, Jul 26, 2023 at 01:52:37PM +0200, Geert Uytterhoeven wrote:
> On Wed, Jul 26, 2023 at 12:00 PM Maxime Ripard wrote:
> > On Tue, Jul 25, 2023 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
> > > > --- a/drivers/gpu/drm/solomon/ssd130x.c
> > > > +++ b/drivers/gpu/drm/solomon/ssd130x.c
On 7/26/2023 8:30 AM, Jeffrey Hugo wrote:
On 7/25/2023 5:40 AM, Colin Ian King wrote:
Pointer pexec is being assigned a value however it is never read. The
assignment is redundant and can be removed.
Signed-off-by: Colin Ian King
---
drivers/accel/qaic/qaic_data.c | 1 -
1 file changed,
On 2023-07-05 10:30:25 [+0100], Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
> preempt disable section over the hardware reset callback to prepare the
> driver for being able to reset from atomic contexts.
>
…
This looks
Adding a reserved memory region for the framebuffer memory
(the splash memory region set up by the bootloader).
It fixes a kernel panic (arm-smmu: Unhandled context fault
at this particular memory region) reported on DB845c running
v5.10.y.
Cc: sta...@vger.kernel.org # v5.10+
Reviewed-by: Caleb
Add and document the reserved memory region property in the
mdss-common schema.
For now (sdm845-db845c), it points to a framebuffer memory
region reserved by the bootloader for splash screen.
Acked-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Signed-off-by: Amit Pundir
---
v6: Re-sending
On Tue, 25 Jul 2023 13:34:35 -0700, Douglas Anderson wrote:
>
> The big motivation for this patch series is mostly described in the patch
> ("drm/panel: Add a way for other devices to follow panel state"), but to
> quickly summarize here: for touchscreens that are connected to a panel we
> need
On Wed, Jul 26, 2023 at 12:55 PM Javier Martinez Canillas
wrote:
> There is only a single caller for both helper functions and these don't do
> much other than allocate and free two buffers, so let's just inline them.
>
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Javier Martinez Canillas
Hi,
On Tue, Jul 25, 2023 at 01:34:37PM -0700, Douglas Anderson wrote:
> NOTE: arguably, the right thing to do here is actually to skip this
> patch and simply remove all the extra checks from the individual
> drivers. Perhaps the checks were needed at some point in time in the
> past but maybe
Hi Javier,
On Wed, Jul 26, 2023 at 2:22 PM Javier Martinez Canillas
wrote:
> Geert Uytterhoeven writes:
> > On Wed, Jul 26, 2023 at 12:00 PM Maxime Ripard wrote:
> >> On Tue, Jul 25, 2023 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
> >> > > --- a/drivers/gpu/drm/solomon/ssd130x.c
> >> > >
Geert Uytterhoeven writes:
> Hi Javier,
>
> On Wed, Jul 26, 2023 at 12:55 PM Javier Martinez Canillas
> wrote:
>> Drivers are not allowed to fail after drm_atomic_helper_swap_state() has
>> been called and the new atomic state is stored into the current sw state.
>>
>> Since the struct
Geert Uytterhoeven writes:
Hello Geert,
> Hi Maxime,
>
> On Wed, Jul 26, 2023 at 12:00 PM Maxime Ripard wrote:
>> On Tue, Jul 25, 2023 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
>> > > --- a/drivers/gpu/drm/solomon/ssd130x.c
>> > > +++ b/drivers/gpu/drm/solomon/ssd130x.c
>> > > @@ -141,12
Hi Javier,
On Wed, Jul 26, 2023 at 12:55 PM Javier Martinez Canillas
wrote:
> Drivers are not allowed to fail after drm_atomic_helper_swap_state() has
> been called and the new atomic state is stored into the current sw state.
>
> Since the struct ssd130x_device .data_array is allocated in the
Hi Maxime,
On Wed, Jul 26, 2023 at 12:00 PM Maxime Ripard wrote:
> On Tue, Jul 25, 2023 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
> > > --- a/drivers/gpu/drm/solomon/ssd130x.c
> > > +++ b/drivers/gpu/drm/solomon/ssd130x.c
> > > @@ -141,12 +141,26 @@ const struct ssd130x_deviceinfo
On 26/07/2023 11:14, Maarten Lankhorst wrote:
Hey,
On 2023-07-22 00:21, Tejun Heo wrote:
On Wed, Jul 12, 2023 at 12:46:04PM +0100, Tvrtko Ursulin wrote:
$ cat drm.memory.stat
card0 region=system total=12898304 shared=0 active=0
resident=12111872 purgeable=167936
card0
On 26/07/2023 12:11, Roger Sewell wrote:
Jocelyn,
How can I check for sure whether I am using 24 or 32 bits per pixel
?
The easiest solution if you already rebuilt your kernel is to print
the variable bpp here:
On Wed, Jul 26, 2023, at 12:54, Uwe Kleine-König wrote:
> On Wed, Jul 26, 2023 at 06:06:26PM +0800, Zhu Wang wrote:
>>
>> Fixes: 5d97408e0d70 ("drm/bridge: move ANA78xx driver to analogix
>> subdirectory")
This is the wrong commit, the driver was just in a different place
before that, and the
On 13/07/2023 18:52, Amit Pundir wrote:
> Adding a reserved memory region for the framebuffer memory
> (the splash memory region set up by the bootloader).
>
> Signed-off-by: Amit Pundir
> ---
I think your commit msg misses describing the actual problem, impact to
users and finally cc-stable.
On 13/07/2023 18:52, Amit Pundir wrote:
> Add and document the reserved memory region property in the
> mdss-common schema.
>
> For now (sdm845-db845c), it points to a framebuffer memory
> region reserved by the bootloader for splash screen.
>
> Signed-off-by: Amit Pundir
> ---
Acked-by:
[Cc += Arnd, Andy who did similar changes in the past]
Hello,
On Wed, Jul 26, 2023 at 06:06:26PM +0800, Zhu Wang wrote:
> When building with W=1, the following warning occurs.
>
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c:48:17: warning:
> ‘anx781x_i2c_addresses’ defined but not used
Drivers are not allowed to fail after drm_atomic_helper_swap_state() has
been called and the new atomic state is stored into the current sw state.
Since the struct ssd130x_device .data_array is allocated in the encoder's
.atomic_enable callback, the operation can fail and this is after the new
There is only a single caller for both helper functions and these don't do
much other than allocate and free two buffers, so let's just inline them.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/solomon/ssd130x.c | 55
Maxime Ripard writes:
Hello Maxime,
> On Tue, Jul 25, 2023 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
>> > --- a/drivers/gpu/drm/solomon/ssd130x.c
>> > +++ b/drivers/gpu/drm/solomon/ssd130x.c
>> > @@ -141,12 +141,26 @@ const struct ssd130x_deviceinfo ssd130x_variants[] =
>> > {
>> > };
>>
Hey,
On 2023-07-22 00:21, Tejun Heo wrote:
On Wed, Jul 12, 2023 at 12:46:04PM +0100, Tvrtko Ursulin wrote:
$ cat drm.memory.stat
card0 region=system total=12898304 shared=0 active=0 resident=12111872
purgeable=167936
card0 region=stolen-system total=0 shared=0 active=0 resident=0
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
What's the status wrt to this regression (caused by 8ddce13ae69 from
Marek)? It looks like things are stalled and the regression still is
unresolved, but I ask because I
On Tue, Jul 25, 2023 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
> > --- a/drivers/gpu/drm/solomon/ssd130x.c
> > +++ b/drivers/gpu/drm/solomon/ssd130x.c
> > @@ -141,12 +141,26 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
> > };
> > EXPORT_SYMBOL_NS_GPL(ssd130x_variants,
1 - 100 of 163 matches
Mail list logo
