Hi Jia-Ju,
interesting that you have found those issues with an automated tool.
And yes that is a well design flaw within the radeon driver which can
happen on hardware faults, e.g. when radeon_ring_backup() needs to be
called.
But that happens so rarely and the driver is not developed
Am 01.02.22 um 01:36 schrieb Lucas De Marchi:
On Fri, Jan 28, 2022 at 10:48:42AM +0100, Christian König wrote:
Am 28.01.22 um 10:40 schrieb Lucas De Marchi:
On Fri, Jan 28, 2022 at 10:22:00AM +0100, Christian König wrote:
Am 28.01.22 um 10:12 schrieb Lucas De Marchi:
On Fri, Jan 28, 2022 at
Hello,
My static analysis tool reports a possible deadlock in the radeon driver
in Linux 5.16:
#BUG 1
radeon_dpm_change_power_state_locked()
mutex_lock(>ring_lock); --> Line 1133 (Lock A)
radeon_fence_wait_empty()
radeon_fence_wait_seq_timeout()
Genralize the helper for getting DSC slice count and compressed bpp
for HDMI sink supporting DSC.
This patch:
-Removes the assumption on the bpc and sends it as an argument for
calculating compressed bpc.
-Sends the resolution, and output format as parameters for which the
DSC paremeters are to be
Misc fixes and refactoring in HDMI2.1 PCON helper functions.
V2:
Addressed review comments from Jani.
Splitted the drm_helper addition and usage in separate patches.
Ankit Nautiyal (4):
drm/i915/hdmi: Fix the definition of intel_hdmi_dsc_get_bpp
drm/edid: Add helper to get max FRL rate for an
Re-use the drm helpers for getting max FRL rate for an HDMI sink.
This patch removes the duplicate code and calls the already defined
drm helpers for the task.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 19 +--
1 file changed, 5 insertions(+), 14
Fix the data-type of the argument output_format to enum, for the
function intel_hdmi_dsc_get_bpp.
v2: Fixed formatting issues in commit message (Jani).
Avoided including the header intel_display_types.h, instead used
forward declaration for the appropriate enum. (Jani).
Fixes: 6e6cb758e035
Add the helpers for getting the max FRL rate with and without DSC
for an HDMI sink.
v2: Fix the subject line and documentation of the helpers (Jani).
Split the helper definitions and usage into separate patches. (Jani).
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 38
From: Alex Sierra
The intention is to test device coherent type pages that have been
called through get user pages with PIN_LONGTERM flag set. These pages
should get migrated back to normal system memory.
Signed-off-by: Alex Sierra
Signed-off-by: Alistair Popple
---
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these pages. These are
coherent and
migrate_vma_setup() checks that a valid vma is passed so that the page
tables can be walked to find the pfns associated with a given address
range. However in some cases the pfns are already known, such as when
migrating device coherent pages during pin_user_pages() meaning a valid
vma isn't
Device coherent pages represent memory on a coherently attached device such
as a GPU which is usually under the control of a driver. These pages should
not be pinned as the driver needs to be able to move pages as required.
Currently this is enforced by failing any attempt to pin a device coherent
The i915_ttm_accel_move() function may return error codes that should
be propagated further up the stack rather than consumed assuming that
the accel move failed and could be replaced with a memcpy move.
For -EINTR, -ERESTARTSYS and -EAGAIN, just propagate those codes, rather
than retrying with a
The print function dev_err() is redundant because platform_get_irq()
already prints an error.
Eliminate the follow coccicheck warning:
./drivers/video/fbdev/pxa3xx-gcu.c:615:2-9: line 615 is redundant because
platform_get_irq() already prints an error
Reported-by: Abaci Robot
Signed-off-by:
The print function dev_err() is redundant because platform_get_irq()
already prints an error.
Eliminate the follow coccicheck warning:
./drivers/video/fbdev/pxa168fb.c:621:2-9: line 621 is redundant because
platform_get_irq() already prints an error
Reported-by: Abaci Robot
Signed-off-by: Yang
On Mon, Jan 31, 2022 at 04:39:04PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 11:28:39AM +0100, Oleksij Rempel wrote:
> > The gpio1 0 pin is controlling CAN termination, not USB H1 VBUS. So,
> > remove wrong regulator and assign this gpio to new DT CAN termnation
>
Hi Sam,
On Mon, Jan 31, 2022 at 04:42:06PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 11:28:40AM +0100, Oleksij Rempel wrote:
> > The tsc2046 is an ADC used as touchscreen controller. To share as mach
> much
> > code as
Hey,
> I think there are more places affected with this change. I can get below
> compilation issues while trying to compile my branch:
>
> drivers/gpu/drm/vc4/vc4_txp.c: In function ‘encoder_to_vc4_txp’:
> ./include/linux/build_bug.h:78:41: error: static assertion failed:
> "pointer type
On Wed, 29 Dec 2021 18:03:54 +0100, Luca Weiss wrote:
> Add and enable PM6150L wled which is used for controlling the display
> backlight on Fairphone 4.
>
> This series depends on the recent wled series by Marijn Suijten,
> currently applied in the for-backlight-next branch of
>
On Sun, 23 Jan 2022 17:38:15 +, Caleb Connolly wrote:
> From: Alexander Martinz
>
> Add initial support for the SHIFT SHIFT6mq (axolotl) based on
> the sdm845-mtp DT.
>
> Currently supported features:
> * Buttons (power, volume)
> * Bluetooth, DSPs and modem
> * Display and GPU
> * Touch
>
On 19/01/2022 03:10, abhin...@codeaurora.org wrote:
On 2021-08-17 20:30, abhin...@codeaurora.org wrote:
On 2021-06-17 15:20, Dmitry Baryshkov wrote:
DPU interrupts code allows multiple callbacks per interrut. In reality
/interrupt
none of the interrupts is shared between blocks (and will
On Tue, 1 Feb 2022 at 06:16, Dmitry Baryshkov
wrote:
>
> On Tue, 1 Feb 2022 at 01:24, Kuogee Hsieh wrote:
> >
> >
> > On 1/28/2022 8:59 PM, Dmitry Baryshkov wrote:
> > > Hi,
> > >
> > > Thank you for your patch.
> > >
> > > On Fri, 28 Jan 2022 at 20:29, Kuogee Hsieh
> > > wrote:
> > >>
On Fri 28 Jan 09:29 PST 2022, Kuogee Hsieh wrote:
> Normally, mdp will push one pixel of data per pixel clock to
> interface to display. Wide bus feature will increase bus
> width from 32 bits to 64 bits so that it can push two
> pixel of data per pixel clock to interface to display.
> This
On Tue, 1 Feb 2022 at 01:24, Kuogee Hsieh wrote:
>
>
> On 1/28/2022 8:59 PM, Dmitry Baryshkov wrote:
> > Hi,
> >
> > Thank you for your patch.
> >
> > On Fri, 28 Jan 2022 at 20:29, Kuogee Hsieh wrote:
> >> Normally, mdp will push one pixel of data per pixel clock to
> >> interface to display.
In function do_fb_ioctl(), the "arg" is the type of unsigned long,
and in "case FBIOBLANK:" this argument is casted into an int before
passig to fb_blank(). In fb_blank(), the comparision
if (blank > FB_BLANK_POWERDOWN) would be bypass if the original
"arg" is a large number, which is possible
On 27/01/2022 02:46, Kuogee Hsieh wrote:
DP driver is a generic driver which supports both eDP and DP.
For debugging purpose it is required to have capabilities to
differentiate message are generated from eDP or DP.
This patch do:
1) add connector type into debug messages within dp_display.c
2)
Hi Suraj
I think there are more places affected with this change. I can get below
compilation issues while trying to compile my branch:
drivers/gpu/drm/vc4/vc4_txp.c: In function ‘encoder_to_vc4_txp’:
./include/linux/build_bug.h:78:41: error: static assertion failed:
"pointer type mismatch
On Fri, Jan 28, 2022 at 10:48:42AM +0100, Christian König wrote:
Am 28.01.22 um 10:40 schrieb Lucas De Marchi:
On Fri, Jan 28, 2022 at 10:22:00AM +0100, Christian König wrote:
Am 28.01.22 um 10:12 schrieb Lucas De Marchi:
On Fri, Jan 28, 2022 at 09:41:14AM +0100, Christian König wrote:
Rule
Hello Sam,
Thanks for your suggestions.
On 1/31/22 22:30, Sam Ravnborg wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 09:29:16PM +0100, Javier Martinez Canillas wrote:
>> Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
>> controllers that can be programmed via an I2C
On 1/31/22 21:56, Sam Ravnborg wrote:
> Hi Javier,
> On Mon, Jan 31, 2022 at 09:12:20PM +0100, Javier Martinez Canillas wrote:
>> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
>> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
>>
>> Using the
Oh sorry, I had looked at this but forgotten to add my reviewed by:
Reviewed-by: Alistair Popple
On Tuesday, 1 February 2022 10:27:25 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
> Hi Alistair,
> This is the last patch to be reviewed from this series. It already has
> the changes from
> your
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head: ea33c6d63f87e34b14dba6f2804990a5fc5a60d7
commit: 2e872d87cbf2cd02dca570ee187cf35567576a70 [6/7] drm/i915: delete shadow
"ret" variable
config: x86_64-randconfig-a003-20220131
(https://download.01.org/0day-
Hi Alistair,
This is the last patch to be reviewed from this series. It already has
the changes from
your last feedback (V3). Would you mind to take a look?
Thanks a lot for reviewing the rest!
Regards,
Alex Sierra
On 1/28/2022 2:08 PM, Alex Sierra wrote:
Test cases such as migrate_fault and
On 1/31/22 21:52, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 09:12:21PM +0100, Javier Martinez Canillas wrote:
>> There isn't a connector type for display controllers accesed through I2C,
>> most drivers use DRM_MODE_CONNECTOR_Unknown or DRM_MODE_CONNECTOR_VIRTUAL.
>>
>> Add an I2C connector
Hello Sam,
Thanks a lot for your feedback.
On 1/31/22 21:46, Sam Ravnborg wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 09:15:37PM +0100, Javier Martinez Canillas wrote:
>> To make sure that tools like the get_maintainer.pl script will suggest
>> to Cc me if patches are posted for this
Hello Simon,
Thanks for your feedback.
On 1/31/22 21:39, Simon Ser wrote:
> On Monday, January 31st, 2022 at 21:36, Simon Ser wrote:
>
>> This driver only advertises XRGB in ssd1307_formats. It would be nice to
>> expose R8 as well so that user-space can directly produce suitable buffers.
Thanks for fixing. I'm guessing Andrew will want you to resend this as part of
a new v6 series, but please add:
Reviewed-by: Alistair Popple
On Tuesday, 1 February 2022 6:48:13 AM AEDT Alex Sierra wrote:
> This case is used to migrate pages from device memory, back to system
> memory. Device
On Wed 19 Jan 09:21 CST 2022, Akhil P Oommen wrote:
> Update the name in the gpulist for 7c3 gpu as per the latest
> recommendation.
>
I was skeptical when this was introduced and you proved my point. Give
it a name based on the Adreno revision or possibly the part number and
leave it at that.
On Wed 19 Jan 09:21 CST 2022, Akhil P Oommen wrote:
> Add the speedbin fuse and the required opps to support gpu sku.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> (no changes since v1)
>
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 46
>
> 1 file changed, 46
On Wed 19 Jan 09:21 CST 2022, Akhil P Oommen wrote:
> Add support for "Adreno 8c Gen 3" gpu along with the necessary speedbin
> support.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> Changes in v2:
> - Fix a bug in adreno_cmp_rev()
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 21
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/i915_vma.c: In function 'i915_vma_bind':
drivers/gpu/drm/i915/i915_vma.c:451:25: error: 'ret' undeclared (first use in
this function); did you mean 'net'?
451
On 1/28/2022 8:59 PM, Dmitry Baryshkov wrote:
Hi,
Thank you for your patch.
On Fri, 28 Jan 2022 at 20:29, Kuogee Hsieh wrote:
Normally, mdp will push one pixel of data per pixel clock to
interface to display. Wide bus feature will increase bus
width from 32 bits to 64 bits so that it can
[+to Maarten, Maxime, Thomas; beginning of thread:
https://lore.kernel.org/r/20220106000658.243509-1-helg...@kernel.org]
On Wed, Jan 05, 2022 at 06:06:48PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Current default VGA device selection fails in some cases because part of it
> is done
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "ssd1307"
> +#define
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
Cc: Jens Frederich
Cc: Jon Nettleton
Cc: Greg Kroah-Hartman
Cc: linux-stag...@lists.linux.dev
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc:
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Signed-off-by: Daniel Vetter
Cc: Daniel
It doesn't ever fail anymore.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Greg Kroah-Hartman
Cc: Claudio Suarez
Cc: Du Cheng
Cc: Tetsuo Handa
---
drivers/video/fbdev/core/fbcon.c | 37 +++-
1 file changed, 13 insertions(+), 24
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Claudio Suarez
Cc: Greg
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Signed-off-by: Daniel
It's only one flag and slightly tidier code.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Tetsuo Handa
Cc: Greg Kroah-Hartman
Cc: Du Cheng
Cc: Thomas Zimmermann
Cc: Claudio Suarez
---
drivers/video/fbdev/core/fbcon.c | 11 +--
drivers/video/fbdev/core/fbcon.h | 4 +---
2
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Tetsuo Handa
Cc: Thomas
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected
It was only used by fbcon, and that now switched to its own,
private work.
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index
This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
option.
References:
https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723...@gmx.de/
Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling")
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev
This reverts commit b3ec8cdf457e ("fbdev: Garbage collect fbdev
scrolling acceleration, part 1 (from TODO list)"), but with a twist:
Because distros like fedora (probably more) really want to move
away from fbcon as much as possible, and don't have a need for fancy
accelerated fbcon even less,
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Signed-off-by:
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
Signed-off-by: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Greg Kroah-Hartman
---
drivers/video/fbdev/core/fbcon.c |
Ever since Tomi extracted the core code in 2014 it's been defacto me
maintaining this, with help from others from dri-devel and sometimes
Linus (but those are mostly merge conflicts):
$ git shortlog -ns drivers/video/fbdev/core/ | head -n5
35 Daniel Vetter
23 Linus Torvalds
10
Hi all,
This took way longer than I hoped, but well I got lost in head-scratching
locking problems. Anyway ended up typing a pile of fbcon patches. Rough
overview:
- MAINTAINER entry for fbdev core in drm-misc, with the usual group
maintainering
- The reverts, but with a compile time option.
DPU driver contains code to parse clock items from device tree into
special data struct and then enable/disable/set rate for the clocks
using that data struct. However the DPU driver itself uses only parsing
and enabling/disabling part (the rate setting is used by DP driver).
Move this
In order to simplify DP code, drop hand-coded loops over clock arrays,
replacing them with clk_bulk_* functions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/dp/dp_clk_util.c | 120 ---
msm_dss_clk_*() functions significantly duplicate clk_bulk_* family of
functions. Drop custom code and use bulk clocks directly. This also
removes dependency of DP driver on the DPU driver internals.
Changes since v3:
- Switched to devm_clk_bulk_get_all() per Stephen's suggestion.
- Removed a
On 31/01/2022 23:50, Kuogee Hsieh wrote:
On 1/28/2022 8:59 PM, Dmitry Baryshkov wrote:
Hi,
Thank you for your patch.
On Fri, 28 Jan 2022 at 20:29, Kuogee Hsieh
wrote:
Normally, mdp will push one pixel of data per pixel clock to
interface to display. Wide bus feature will increase bus
Hi Javier,
On Mon, Jan 31, 2022 at 09:12:20PM +0100, Javier Martinez Canillas wrote:
> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
>
> Using the DRM fb emulation, all the tests from Geert
On Mon, Jan 31, 2022 at 09:12:21PM +0100, Javier Martinez Canillas wrote:
> There isn't a connector type for display controllers accesed through I2C,
> most drivers use DRM_MODE_CONNECTOR_Unknown or DRM_MODE_CONNECTOR_VIRTUAL.
>
> Add an I2C connector type to match the actual connector.
>
> As
On 1/28/2022 8:59 PM, Dmitry Baryshkov wrote:
Hi,
Thank you for your patch.
On Fri, 28 Jan 2022 at 20:29, Kuogee Hsieh wrote:
Normally, mdp will push one pixel of data per pixel clock to
interface to display. Wide bus feature will increase bus
width from 32 bits to 64 bits so that it can
Hi Javier,
On Mon, Jan 31, 2022 at 09:15:37PM +0100, Javier Martinez Canillas wrote:
> To make sure that tools like the get_maintainer.pl script will suggest
> to Cc me if patches are posted for this driver.
>
> Also include the Device Tree binding for the old ssd1307fb fbdev driver
> since the
On Tue, Nov 30, 2021 at 04:27:55PM +0100, Daniel Vetter wrote:
> Hammer it a bit more in that iterators can be restarted and when that
> matters, plus suggest to prefer the locked version whenver.
>
> Also delete the two leftover kerneldoc for static functions plus
> sprinkle some more links
Hi all,
On 2021-12-22 19:31, Dmitry Osipenko wrote:
22.12.2021 22:30, Jon Hunter пишет:
On 22/12/2021 19:01, Dmitry Osipenko wrote:
...
diff --git a/drivers/gpu/host1x/syncpt.c
b/drivers/gpu/host1x/syncpt.c
index e08e331e46ae..8194826c9ce3 100644
--- a/drivers/gpu/host1x/syncpt.c
+++
On Sat, Jan 29, 2022 at 7:06 AM Jordy Zomer wrote:
>
> It appears like nr could be a Spectre v1 gadget as it's supplied by a
> user and used as an array index. Prevent the contents
> of kernel memory from being leaked to userspace via speculative
> execution by using array_index_nospec.
>
>
On Monday, January 31st, 2022 at 21:36, Simon Ser wrote:
> This driver only advertises XRGB in ssd1307_formats. It would be nice to
> expose R8 as well so that user-space can directly produce suitable buffers.
> It would also be nice to have some kind of preferred format, so that
>
This driver only advertises XRGB in ssd1307_formats. It would be nice to
expose R8 as well so that user-space can directly produce suitable buffers.
It would also be nice to have some kind of preferred format, so that user-space
knows R8 is preferred over XRGB.
ude
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"ssd1307"
+#define DRIVER_DESC"DRM driver for Solomon SSD1307 OLED displays"
+#define DRIVER_DATE"20220131"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+#define SS
To make sure that tools like the get_maintainer.pl script will suggest
to Cc me if patches are posted for this driver.
Also include the Device Tree binding for the old ssd1307fb fbdev driver
since the new DRM driver was made compatible with the existing binding.
Signed-off-by: Javier Martinez
Applied. Thanks!
Alex
On Mon, Jan 31, 2022 at 10:17 AM Harry Wentland wrote:
>
> On 2022-01-28 20:04, Yang Li wrote:
> > Eliminate the follow smatch warning:
> > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c:2246
> > dp_perform_8b_10b_link_training() warn: inconsistent indenting
> >
> >
There isn't a connector type for display controllers accesed through I2C,
most drivers use DRM_MODE_CONNECTOR_Unknown or DRM_MODE_CONNECTOR_VIRTUAL.
Add an I2C connector type to match the actual connector.
As Noralf Trønnes mentions in commit fc06bf1d76d6 ("drm: Add SPI connector
type"),
This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest
(https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git)
Add support to convert 8-bit grayscale to reversed monochrome for drivers
that control monochromatic displays, that only have 1 bit per pixel depth.
This helper function was based on repaper_gray8_to_mono_reversed() from
the drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-by: Javier Martinez
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
---
v2:
condition added when migrations from device coherent pages.
---
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
v6:
*
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
Signed-off-by:
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from
https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for
On Mon, 31 Jan 2022 at 17:55, Hsin-Yi Wang wrote:
>
> On Tue, Feb 1, 2022 at 12:37 AM Robert Foss wrote:
> >
> > On Thu, 20 Jan 2022 at 16:25, AngeloGioacchino Del Regno
> > wrote:
> > >
> > > Il 14/01/22 10:14, allen ha scritto:
> > > > This adds support for the iTE IT6505.
> > > > This device
On Fri, 24 Dec 2021 21:33:09 +0530, Sankeerth Billakanti wrote:
> Add display devicetree support for sc7280 platform.
>
> Krishna Manikandan (1):
> arm64: dts: qcom: sc7280: add display dt nodes
>
> Kuogee Hsieh (1):
> arm64: dts: qcom: sc7280: Add Display Port node
>
> [...]
Applied,
On Mon, 22 Nov 2021 16:59:15 +0530, Sankeerth Billakanti wrote:
> From: Kuogee Hsieh
>
>
Applied, thanks!
[4/4] arm64: dts: qcom: sc7280: Add Display Port node
commit: fc6b1225d20de0298a7b0e52eb3843d71e1992e8
Best regards,
--
Bjorn Andersson
On Mon, 22 Nov 2021 16:56:06 +0530, Sankeerth Billakanti wrote:
> From: Krishna Manikandan
>
> Add mdss and mdp DT nodes for sc7280.
>
>
Applied, thanks!
[1/4] arm64: dts: qcom: sc7280: add display dt nodes
commit: fcb68dfda5cbd816d27ac50c287833848874f61c
[2/4] arm64: dts: qcom:
From: Svyatoslav Ryhel
Add HannStar HSD101PWW2 10.1" WXGA (1280x800) TFT-LCD LVDS panel
to the list of compatibles.
Acked-by: Rob Herring
Signed-off-by: Svyatoslav Ryhel
Signed-off-by: Dmitry Osipenko
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file
From: Anton Bambura
LQ101R1SX03 is compatible with LQ101R1SX01 from software perspective,
document it. The LQ101R1SX03 is a newer revision of LQ101R1SX01, it has
minor differences in hardware pins in comparison to the older version.
The newer version of the panel can be found on Android tablets,
From: Svyatoslav Ryhel
Add definition of the HannStar HSD101PWW2 Rev0-A00/A01 LCD
SuperIPS+ HD panel.
Signed-off-by: Svyatoslav Ryhel
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git
1 - 100 of 174 matches
Mail list logo
