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
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
Reviewed-by: Harry Wentland
Harry
> ---
>
On 30/01/2022 23:15, Rajeev Nandan wrote:
The clock and data lanes of the DSI PHY have a calibration circuitry
feature. As per the MSM DSI PHY tuning guidelines, the drive strength
tuning can be done by adjusting rescode offset for hstop/hsbot, and
the drive level tuning can be done by adjusting
On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote:
> > The component framework only provides 'bind' and 'unbind' callbacks to
> > tell the host driver that it is time to assemble the aggregate driver
> > now that all the
On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote:
> On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote:
> > > The component framework only provides 'bind' and 'unbind' callbacks to
> > > tell the host
On 1/26/22 16:21, Matthew Auld wrote:
If the user doesn't require CPU access for the buffer, then
ALLOC_TOPDOWN should be used, in order to prioritise allocating in the
non-mappable portion of LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
I was wondering how this would work best
Hey Christophe,
Thanks for submitting this fix.
On Sat, 29 Jan 2022 at 16:06, Christophe JAILLET
wrote:
>
> If lt9611_audio_init() fails, some resources still need to be released
> before returning an error code.
>
> Add the missing goto the error handling path.
>
> Fixes: 23278bf54afe
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 can convert DPI signal to DP output.
> >
> > From: Allen Chen
> > Tested-by: Hsin-yi Wang
> > Signed-off-by: Hermes Wu
> >
panel-edp calls into drm-kms-helper module (by calling
drm_panel_dp_aux_backlight), so it should depend on respective module.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/Kconfig
Am Montag, 31. Januar 2022, 17:54:39 CET schrieb
quentin.sch...@theobroma-systems.com:
> From: Quentin Schulz
>
> Heiko does not work at Theobroma Systems anymore and the boards using
> those panels are downstream, maintained internally by the company, so
> let's relieve Heiko of maintainership
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
Architectures others than x86 have a stub implementation calling
WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
the header-test target will fail with:
HDRTEST drivers/gpu/drm/i915/i915_mm.h
In file included from :
./drivers/gpu/drm/i915/i915_mm.h: In function
Some minor fixes and changes to help porting i915 to arm64, or even
anything !x86.
v3: No changes, just submit to the right mailing list.
Lucas De Marchi (3):
drm: Stop spamming log with drm_cache message
drm/i915: Fix header test for !CONFIG_X86
drm/i915: Do not spam log with missing arch
Following what was done in drm_cache.c, when the stub for
remap_io_mapping() was added in commit 67c430bbaae1 ("drm/i915: Skip
remap_io_mapping() for non-x86 platforms"), it included a log message
with pr_err(). However just the warning is already enough and switching
to WARN_ONCE() allows us to
Only x86 and in some cases PPC have support added in drm_cache.c for the
clflush class of functions. However warning once is sufficient to taint
the log instead of spamming it with "Architecture has no drm_cache.c
support" every few millisecond. Switch to WARN_ONCE() so we still get
the log
This series adds support for Sharp LQ101R1SX03 and HannStar HSD101PWW2
display panels that are used by Asus Transformer tablets, which we're
planning to support since 5.17 kernel.
Changelog:
v4: - Added r-b from Rob Herring that he gave to the LQ101R1SX01 DT patch
of v2. I missed to add it
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
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 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
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 can convert DPI signal to DP output.
> > >
> > > From: Allen Chen
>
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:
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 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, 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
termination
> property.
>
>
On 1/26/22 16:21, Matthew Auld wrote:
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
Signed-off-by: Matthew Auld
Cc:
On Thu, 27 Jan 2022 at 02:10, Laurent Pinchart
wrote:
>
> Hi Yongzhi,
>
> Thank you for the patch.
>
> On Sun, Jan 23, 2022 at 11:20:35PM -0800, Yongzhi Liu wrote:
> > pm_runtime_get_sync() will increase the rumtime PM counter
> > even when it returns an error. Thus a pairing decrement is needed
Hi Daniel,
On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote:
> On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman wrote:
> > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote:
> > > The component framework only provides 'bind' and 'unbind' callbacks to
> > > tell the host
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 possible, we should use it as actual ADC + virtual touchscreen
> controller.
>
On 31/01/2022 15:28, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
If the user doesn't require CPU access for the buffer, then
ALLOC_TOPDOWN should be used, in order to prioritise allocating in the
non-mappable portion of LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
On 1/26/22 16:21, Matthew Auld wrote:
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the
On Mon, 31 Jan 2022 at 17:25, Robert Foss wrote:
>
> Hey Christophe,
>
> Thanks for submitting this fix.
>
> On Sat, 29 Jan 2022 at 16:06, Christophe JAILLET
> wrote:
> >
> > If lt9611_audio_init() fails, some resources still need to be released
> > before returning an error code.
> >
> > Add
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.
>
>
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 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
>
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
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
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.
---
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
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
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:
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 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)
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"),
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
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
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
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: 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
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
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
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
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,
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
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
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
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
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
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:
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 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")
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 |
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:
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
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
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().
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
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
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
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "ssd1307"
> +#define
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
> >
> >
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
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.
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 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
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 ---
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
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.
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
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
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.
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 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
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)
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 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.
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 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 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 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
>
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:
> 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
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.
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 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 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
>
1 - 100 of 174 matches
Mail list logo
