Hi,
On Fri, Apr 17, 2020 at 11:08 AM Laurent Pinchart
wrote:
>
> As for the hpd-gpios, it should be specified in the DT node of the
> component that provides the HPD signal, and contain a GPIO specifier
> describing what the signal is connected to. When dealing with a physical
> DP connector and
Hi,
On Wed, Apr 15, 2020 at 1:31 PM Laurent Pinchart
wrote:
>
> Hi Douglas,
>
> Thank you for the patch.
>
> On Wed, Apr 15, 2020 at 08:48:39AM -0700, Douglas Anderson wrote:
> > This moves the bindings over, based a lot on toshiba,tc358768.yaml.
> > Unless there's someone known to be better,
We don't have the HPD line hooked up to the bridge chip. Add it as
suggested in the patch ("dt-bindings: drm/bridge: ti-sn65dsi86:
Document no-hpd").
NOTE: this patch isn't expected to have any effect but just keeps us
cleaner for the future. Currently the driver in Linux just assumes
that
This moves the bindings over, based a lot on toshiba,tc358768.yaml.
Unless there's someone known to be better, I've set the maintainer in
the yaml as the first person to submit bindings.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- specification => specifier.
- power up => power.
-
As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
kinda useless, at least for embedded DisplayPort (eDP). However,
despite the fact that the actual HPD pin on the bridge is mostly
useless for eDP, the concept of
In the cases where there is no connector in a system there's no great
place to put "hpd-gpios". As per discussion [1] the best place to put
it is in the panel. Add this to the device tree bindings.
[1] https://lore.kernel.org/r/20200417180819.ge5...@pendragon.ideasonboard.com
Signed-off-by:
People use panel-simple when they have panels that are builtin to
their device. In these cases the HPD (Hot Plug Detect) signal isn't
really used for hotplugging devices but instead is used for power
sequencing. Panel timing diagrams (especially for eDP panels) usually
have the HPD signal in
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
be used as GPIOs in a system. Each pin can be configured as input,
output, or a special function for the bridge chip. These are:
- GPIO1: SUSPEND Input
- GPIO2: DSIA VSYNC
- GPIO3: DSIA HSYNC or VSYNC
- GPIO4: PWM
Let's
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware. Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for
Hi Bernard,
Please see comments inline.
Am 2020-04-20 um 10:41 p.m. schrieb Bernard Zhao:
> There is no need to if check again, maybe we could merge
> into the above else branch.
>
> Signed-off-by: Bernard Zhao
>
> ---
> Changes since V1:
> *commit message improve
> *code style refactoring
>
>
Hi Bernard,
Thank you for the patch. Please see some comments inline.
Am 2020-04-20 um 10:25 p.m. schrieb Bernard Zhao:
> Maybe we could reduce the mutex_lock(>lock)`s protected code area,
> and noneed to protect pr_debug.
Typo: noneed -> no need
>
> Signed-off-by: Bernard Zhao
>
> Changes
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc
tree with the drm-misc-fixes tree
drivers/gpu/drm/tidss/tidss_encoder.c
between commit:
9da67433f64e ("drm/tidss: fix crash related to accessing freed memory")
from the drm-misc-fixes tree and commit:
On Mon, 20 Apr 2020 at 18:39, Christophe Leroy wrote:
>
> _ALIGN() is specific to powerpc
> ALIGN() is generic and does the same
>
> Replace _ALIGN() by ALIGN()
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Joel Stanley
> ---
> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
>
On Mon, 20 Apr 2020 at 18:39, Christophe Leroy wrote:
>
> _ALIGN_UP() is specific to powerpc
> ALIGN() is generic and does the same
>
> Replace _ALIGN_UP() by ALIGN()
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Joel Stanley
> ---
> arch/powerpc/include/asm/iommu.h | 4 ++--
On Mon, 20 Apr 2020 at 18:38, Christophe Leroy wrote:
>
> _ALIGN_DOWN() is specific to powerpc
> ALIGN_DOWN() is generic and does the same
>
> Replace _ALIGN_DOWN() by ALIGN_DOWN()
This one is a bit less obvious. It becomes (leaving the typeof's alone
for clarity):
On Mon, 20 Apr 2020 at 18:39, Christophe Leroy wrote:
>
> These three powerpc macros have been replaced by
> equivalent generic macros and are not used anymore.
>
> Remove them.
>
> Signed-off-by: Christophe Leroy
Reviewed-By: Joel Stanley
riscv has a copy of these too that could probably be
On Mon, 20 Apr 2020 at 18:37, Christophe Leroy wrote:
>
> _ALIGN_UP() is specific to powerpc
> ALIGN() is generic and does the same
>
> Replace _ALIGN_UP() by ALIGN()
>
> Signed-off-by: Christophe Leroy
I was curious, so I expanded out the kernel one. Here's the diff:
-
On Sat, 18 Apr 2020 at 05:42, Lyude Paul wrote:
>
> Nvidia released some documentation on how CRC support works on their
> GPUs, hooray!
>
> So: this patch series implements said CRC support in nouveau, along with
> adding some special debugfs interfaces for some relevant igt-gpu-tools
> tests
On Mon, 20 Apr 2020 10:41:15 +0300
Gal Pressman wrote:
> Fix a couple of typos: "as" -> "has" and "int" -> "in".
>
> Signed-off-by: Gal Pressman
Applied, thanks.
jon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Tue, 14 Apr 2020 18:48:26 +0200
Mauro Carvalho Chehab wrote:
> Patches 1 to 5 contain changes to the documentation toolset:
>
> - The first 3 patches help to reduce a lot the number of reported
> kernel-doc issues, by making the tool more smart.
>
> - Patches 4 and 5 are meant to
On Wed, 15 Apr 2020 09:13:18 +0800, Jitao Shi wrote:
> Signed-off-by: Jitao Shi
> ---
> .../bindings/display/mediatek/mediatek,dpi.txt | 42 --
> .../bindings/display/mediatek/mediatek,dpi.yaml| 97
> ++
> 2 files changed, 97 insertions(+), 42 deletions(-)
>
https://bugzilla.kernel.org/show_bug.cgi?id=205291
K J Petrie (kernel.b...@kjpetrie.co.uk) changed:
What|Removed |Added
Attachment #288639|0 |1
is
On Wed, Apr 15, 2020 at 02:29:29AM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
You're going to need to base this on top of Laurent's conversion of
dw_hdmi.txt to schema.
>
> Acked-by: Sam
The Xilinx MIPI DSI Tx Subsystem soft IP is used to display video
data from AXI-4 stream interface.
It supports upto 4 lanes, optional register interface for the DPHY,
multiple RGB color formats, command mode and video mode.
This is a MIPI-DSI host driver and provides DSI bus for panels.
This
MIPI DSI TX subsystem allows you to quickly create systems based on the
MIPI protocol. It interfaces between the video processing subsystems and
MIPI-based displays. An internal high-speed physical layer design, D-PHY,
is provided to allow direct connection to display peripherals.
The subsystem
This add a dt binding for Xilinx DSI TX subsystem.
The Xilinx MIPI DSI (Display serial interface) Transmitter Subsystem
implements the Mobile Industry Processor Interface (MIPI) based display
interface. It supports the interface with the programmable logic (FPGA).
Signed-off-by: Venkateshwar Rao
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #6 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
Comment on attachment 288639
--> https://bugzilla.kernel.org/attachment.cgi?id=288639
dmesg for 4.17.2
Scrub this. It has radeon.runpm=0 on it's command line. I'll upload a
On Mon, Apr 20, 2020 at 12:59 PM Jonathan Marek wrote:
>
> On 4/20/20 3:51 PM, Bjorn Andersson wrote:
> > On Mon 20 Apr 07:03 PDT 2020, Jonathan Marek wrote:
> >
> >> This reverts commit a5fb8b918920c6f7706a8b5b8ea535a7f077a7f6.
> >
> > Why?
> >
>
> It removes something I need for the next
https://bugzilla.kernel.org/show_bug.cgi?id=205291
K J Petrie (kernel.b...@kjpetrie.co.uk) changed:
What|Removed |Added
Hardware|IA-64 |x86-64
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #5 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
(In reply to Alex Deucher from comment #1)
> Can you bisect?
Probably not. I can just about compile a kernel, but finding my way around
anything other than a standard source
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #4 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
Created attachment 288639
--> https://bugzilla.kernel.org/attachment.cgi?id=288639=edit
dmesg for 4.17.2
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #3 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
Created attachment 288637
--> https://bugzilla.kernel.org/attachment.cgi?id=288637=edit
dmesg for 4.16.17
I no longer had the kernels installed so I have used the nearest
On Mon, Apr 13, 2020 at 04:35:53PM +0300, Hadar Gat wrote:
> Both of_platform.h and of_device.h were included each other.
> In of_device.h, removed unneeded #include to of_platform.h
> and added include to of_platform.h in the files that needs it.
Guess we forgot about that temporary comment!
On Mon, Apr 20, 2020 at 1:22 AM Christian Brauner
wrote:
> On Thu, Apr 16, 2020 at 12:25:08PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 14, 2020 at 09:41:31PM -0700, John Stultz wrote:
> > > But I do think we can mark it as deprecated and let folks know that
> > > around the end of the
On Sat, 11 Apr 2020 18:57:00 +0200, Martin Blumenstingl wrote:
> The GPU can be one of the big heat sources on a SoC. Allow the
> "#cooling-cells" property to be specified for ARM Mali Utgard GPUs so
> the GPU clock speeds (and voltages) can be reduced to prevent a SoC from
> overheating.
>
>
Quoting Xiyu Yang (2020-04-20 06:41:54)
> igt_ppgtt_pin_update() invokes i915_gem_context_get_vm_rcu(), which
> returns a reference of the i915_address_space object to "vm" with
> increased refcount.
>
> When igt_ppgtt_pin_update() returns, "vm" becomes invalid, so the
> refcount should be
On Mon, Apr 20, 2020 at 8:04 PM Souptick Joarder wrote:
>
> These are dead code since 3.7. If there is no plan to use them further,
> these can be removed forever.
Thanks. Will apply to drm-misc-next.
Signed-off-by: Patrik Jakobsson
>
> Signed-off-by: Souptick Joarder
> ---
>
On Sat, 11 Apr 2020 15:44:05 +0800, Jitao Shi wrote:
> Add a property to control mipi tx drive current:
> "drive-strength-microamp"
>
> Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
> 1 file changed, 5
Hi Adrian
On Mon, Apr 20, 2020 at 02:19:24PM +0300, Adrian Ratiu wrote:
> Hello,
>
> I got confused while doing the txt -> yaml conversion at [1] and it's still
> not clear to me who should be added in the "maintainers" field. Clearly not
> the maintainers as returned by get_maintainer.pl. :)
>
On Tue, Apr 07, 2020 at 09:17:10PM +0530, Kiran Gunda wrote:
> From: Subbaraman Narayanamurthy
>
> PM8150L WLED supports the following:
> - Two modulators and each sink can use any of the modulator
> - Multiple CABC selection options from which one can be selected/enabled
> -
On Wed, Apr 15, 2020 at 07:55:49PM -0500, Rob Herring wrote:
> json-schema versions draft7 and earlier have a weird behavior in that
> any keywords combined with a '$ref' are ignored (silently). The correct
> form was to put a '$ref' under an 'allOf'. This behavior is now changed
> in the 2019-09
On Wed, Apr 15, 2020 at 07:55:48PM -0500, Rob Herring wrote:
> Fix various inconsistencies in schema indentation. Most of these are
> list indentation which should be 2 spaces more than the start of the
> enclosing keyword. This doesn't matter functionally, but affects running
> scripts which do
On Tue, Apr 07, 2020 at 09:17:09PM +0530, Kiran Gunda wrote:
> Add WLED5 specific bindings.
>
> Signed-off-by: Kiran Gunda
> Signed-off-by: Subbaraman Narayanamurthy
If v6 is just reacting to Rob's feedback then feel free to add the
following when you recirculate:
Acked-by: Daniel Thompson
On Tue, Apr 07, 2020 at 09:17:08PM +0530, Kiran Gunda wrote:
> Add wled_cabc_config, wled_sync_toggle, wled_ovp_fault_status
> and wled_ovp_delay and wled_auto_detection_required callback
> functions to prepare the driver for adding WLED5 support.
>
> Signed-off-by: Kiran Gunda
> Signed-off-by:
On Fri, Apr 17, 2020 at 02:33:12PM +0300, Tomi Valkeinen wrote:
> led_bl_parse_levels() is rather difficult to follow. Rewrite it with a
> more obvious code flow.
... that introduces new behaviour.
There's a couple of new behaviours here but the one that particular
attracted my attention is the
On Fri, Apr 17, 2020 at 02:33:11PM +0300, Tomi Valkeinen wrote:
> The code that maps the LED default brightness to backlight levels has
> two issues: 1) if the default brightness is the first backlight level
> (usually 0), the code fails to find it, and 2) when the code fails to
> find a backlight
On Fri, Apr 17, 2020 at 02:33:10PM +0300, Tomi Valkeinen wrote:
> led_bl does not lock 'led_access' when calling led_sysfs_disable and
> led_sysfs_enable, causing the below WARN. Add the locking.
>
> WARNING: CPU: 0 PID: 223 at drivers/leds/led-core.c:353
> led_sysfs_disable+0x4c/0x5c
>
>
On Sat, Apr 18, 2020 at 7:13 AM Mikhail Gavrilov
wrote:
>
> On Sat, 11 Apr 2020 at 14:56, Christian König
> wrote:
> >
> > Yeah, that is a known issue.
> >
> > You could try the attached patch, but please be aware that it is not
> > even compile tested because of the Easter holidays here.
> >
>
On Fri, Apr 17, 2020 at 02:33:09PM +0300, Tomi Valkeinen wrote:
> There's no need to set 'levels' to NULL.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/led_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Fri, Apr 17, 2020 at 02:33:08PM +0300, Tomi Valkeinen wrote:
> Fix issues reported by checkpatch. No functional changes.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/led_bl.c | 14 --
> 1 file changed, 8 insertions(+), 6
On Fri, Apr 17, 2020 at 05:23:35PM +0800, Jason Yan wrote:
> Fix the following gcc warning:
>
> drivers/video/backlight/qcom-wled.c:939:34: warning: ‘wled4_string_cfg’
> defined but not used [-Wunused-const-variable=]
> static const struct wled_var_cfg wled4_string_cfg = {
>
Am Sa., 18. Apr. 2020 um 12:01 Uhr schrieb Tang Bin
:
>
> In the function etnaviv_gpu_platform_probe(), when get irq failed,
> the function platform_get_irq() logs an error message, so remove
> redundant message here.
>
> Signed-off-by: Tang Bin
Reviewed-by: Christian Gmeiner
> ---
>
On 20/04/20 16:28, Greg Kroah-Hartman wrote:
>> I assume you meant a new file. These new functions are used only by a few
>> filesystems, and I didn't want to include them in vmlinux unconditionally,
>> so I introduced simplefs.c and CONFIG_SIMPLEFS instead of extending libfs.c.
>> In this way
On Mon, Apr 20, 2020 at 10:03:05AM -0400, Jonathan Marek wrote:
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 24 ++
> drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10 +
> 3
On Mon, Apr 20, 2020 at 03:57:48PM +0200, Emanuele Giuseppe Esposito wrote:
>
>
> On 4/14/20 2:56 PM, Greg Kroah-Hartman wrote:
> > On Tue, Apr 14, 2020 at 02:43:00PM +0200, Emanuele Giuseppe Esposito wrote:
> > > A bunch of code is duplicated between debugfs and tracefs, unify it to the
> > >
Hi
Am 20.04.20 um 14:58 schrieb Konstantin Khlebnikov:
>
>
> On 20/04/2020 15.55, Thomas Zimmermann wrote:
>> Hi Konstantin
>>
>> Am 20.04.20 um 14:45 schrieb Konstantin Khlebnikov:
>>> I've stumbled upon this too. Trivial fix was posted but stuck in review.
>>> This is patch from Thomas
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: d0435a9b45070b945578c093dcd363b6b73a502c
commit: 198db0fc276cdf8e1bb66a4a03473dbea1400d18 [18/20] Revert "drm/i915:
Don't select BROKEN"
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Ubuntu
From: Colin Ian King
Currently pointer hive is being dereferenced before it is being null
checked and hence can lead to null pointer dereference issues. Fix this
by only dereferencing pointer hive after it has been null checked.
Addresses-Coverity: ("Dereference before null check")
Fixes:
On Mon, Apr 20, 2020 at 10:14 AM Jani Nikula
wrote:
> On Fri, 17 Apr 2020, Jason Gunthorpe wrote:
> > On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote:
> >> On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote:
> >> >
> >> > If we can agree on these changes, maybe someone
On 4/16/20 8:44 AM, Luis Chamberlain wrote:
On Tue, Apr 14, 2020 at 02:42:55PM +0200, Emanuele Giuseppe Esposito wrote:
aa_mk_null_file is using simple_pin_fs/simple_release_fs with local
variables as arguments, for what would amount to a simple
vfs_kern_mount/mntput pair if everything was
On 4/16/20 8:59 AM, Luis Chamberlain wrote:
On Tue, Apr 14, 2020 at 02:42:54PM +0200, Emanuele Giuseppe Esposito wrote:
This series of patches introduce wrappers for functions,
arguments simplification in functions calls and most importantly
groups duplicated code in a single header,
On 4/14/20 3:01 PM, Greg Kroah-Hartman wrote:
On Tue, Apr 14, 2020 at 02:42:58PM +0200, Emanuele Giuseppe Esposito wrote:
It is a common special case for new_inode to initialize the
time to the current time and the inode to get_next_ino().
Introduce a core function that does it and use it
On 4/14/20 2:56 PM, Greg Kroah-Hartman wrote:
On Tue, Apr 14, 2020 at 02:43:00PM +0200, Emanuele Giuseppe Esposito wrote:
A bunch of code is duplicated between debugfs and tracefs, unify it to the
simplefs library.
The code is very similar, except that dentry and inode creation are unified
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your dmesg output in both the working and non-working cases.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205291
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Fri, Apr 17, 2020 at 05:22:57PM +0800, Jason Yan wrote:
> Fix the following gcc warning:
>
> drivers/video/backlight/lms501kf03.c:96:28: warning: ‘seq_sleep_in’
> defined but not used [-Wunused-const-variable=]
> static const unsigned char seq_sleep_in[] = {
>
Hi
Am 15.04.20 um 09:39 schrieb Daniel Vetter:
> Add a new macro helper to combine the usual init sequence in drivers,
> consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
> triplet. This allows us to remove the rather unsightly
> drmm_add_final_kfree from all currently merged
Hi,
On 4/15/20 7:44 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 05:03:55PM +0200, Hans de Goede wrote:
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
Allows us to drop the cleanup code on the floor.
Sam noticed in his review:
With this change we avoid calling pci_disable_device()
twise
Hi Konstantin
Am 20.04.20 um 14:45 schrieb Konstantin Khlebnikov:
> I've stumbled upon this too. Trivial fix was posted but stuck in review.
> This is patch from Thomas Zimmermann changed according to suggestions by
> Daniel Vetter from https://patchwork.kernel.org/patch/11356157/
Did you find
On Monday, April 20, 2020 2:22 PM, Pekka Paalanen wrote:
> On Mon, 20 Apr 2020 10:15:39 +
> Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, April 20, 2020 10:27 AM, Pekka Paalanen ppaala...@gmail.com
> > wrote:
> >
> > > The only "random" KMS state is the properties the userspace KMS
On Sun, Apr 19, 2020 at 11:25:08AM +0200, Clément Péron wrote:
> Just saw that a Lima devfreq[0] has been also introduced with I think
> exactly the same logic.
> Is this something that hasn't been triggered by Maintainer or I am
> missing something?
My understanding is that there is very
On Mon, 20 Apr 2020 10:15:39 +
Simon Ser wrote:
> On Monday, April 20, 2020 10:27 AM, Pekka Paalanen
> wrote:
>
> > The only "random" KMS state is the properties the userspace KMS
> > program does not know that are set on start-up. I have been assuming
> > that as long as you had fbdev
Hi
IMHO, at some point console support will require a change where there's
a single config option enables/disables fbdev emulation for all drivers.
But this patch is a step in the right direction. Thanks!
Am 17.04.20 um 17:55 schrieb Arnd Bergmann:
> CONFIG_FB causes unnecessary Kconfig
Hello,
I got confused while doing the txt -> yaml conversion at [1] and
it's still not clear to me who should be added in the
"maintainers" field. Clearly not the maintainers as returned by
get_maintainer.pl. :)
Rob mentioned that "owners" should be manintainers but I also have
trouble
On Mon, 13 Apr 2020, Lyude Paul wrote:
> Looks like I accidentally made it so you couldn't force DPCD backlight
> support on, whoops. Fix that.
Thanks, pushed.
BR,
Jani.
>
> Signed-off-by: Lyude Paul
> Fixes: 17f5d57915be ("drm/i915: Force DPCD backlight mode on X1 Extreme 2nd
> Gen 4K
On 17/04/2020 20:14, Daniel Vetter wrote:
> On Fri, Apr 17, 2020 at 6:05 PM Neil Armstrong
> wrote:
>>
>> On 17/04/2020 17:07, Daniel Vetter wrote:
[...]
>
> Yup there's a number of parametried modifiers. As long as the stuff
> you get from a DRM_FORMAT_MOD_ ... macro is a full modifier with
I'd really like a drmModeAtomicAddDefaultProperty that resets a prop
to its default value…
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Monday, April 20, 2020 10:27 AM, Pekka Paalanen wrote:
> The only "random" KMS state is the properties the userspace KMS
> program does not know that are set on start-up. I have been assuming
> that as long as you had fbdev active before the KMS program started,
> the unknown properties have
On Mon, 20 Apr 2020 11:27:04 +0300
Pekka Paalanen wrote:
> On Fri, 17 Apr 2020 16:17:18 +0200
> Daniel Vetter wrote:
>
> > On Fri, Apr 17, 2020 at 11:02 AM Pekka Paalanen
> > wrote:
> > >
> > > Hi,
> > >
> > > let's think about how userspace uses atomic KMS UAPI. The simplest way
> > > to
imx drivers don't require drm encoders and they all had empty/no-op
implementations which got converted to simple objects to pacify the
drm core which still requires something to be defined.
The problem now is that each driver duplicates the same encoder
initialization logic and I'm working on
https://bugzilla.kernel.org/show_bug.cgi?id=206017
--- Comment #17 from udo (udo...@xs4all.nl) ---
Kernel 5.6.x works very well.
Git mesa might help too.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
Hi Christoph,
On Tue, Apr 14, 2020 at 3:21 PM Christoph Hellwig wrote:
> Just use __vmalloc_node instead which gets and extra argument. To be
> able to to use __vmalloc_node in all caller make it available outside
> of vmalloc and implement it in nommu.c.
>
> Signed-off-by: Christoph Hellwig
>
Hi Christoph,
On Tue, Apr 14, 2020 at 3:22 PM Christoph Hellwig wrote:
> Open code it in __bpf_map_area_alloc, which is the only caller. Also
> clean up __bpf_map_area_alloc to have a single vmalloc call with
> slightly different flags instead of the current two different calls.
>
> For this to
Quoting Greg KH (2020-04-14 11:23:44)
> On Tue, Apr 14, 2020 at 09:15:07AM +0100, Chris Wilson wrote:
> > Quoting Greg KH (2020-04-11 12:39:57)
> > > On Fri, Apr 10, 2020 at 07:17:38AM -0700, Sultan Alsawaf wrote:
> > > > On Fri, Apr 10, 2020 at 11:08:38AM +0200, Greg KH wrote:
> > > > > On Tue,
On Fri, 17 Apr 2020 16:17:18 +0200
Daniel Vetter wrote:
> On Fri, Apr 17, 2020 at 11:02 AM Pekka Paalanen wrote:
> >
> > Hi,
> >
> > let's think about how userspace uses atomic KMS UAPI. The simplest way
> > to use atomic correctly is that userspace will for every update send the
> > full,
Quoting Sultan Alsawaf (2020-04-20 08:24:19)
> Chris,
>
> Could you please look at this in earnest? This is a real bug that crashes my
> laptop without any kind of provocation. It is undeniably a bug in i915, and
> I've
> clearly described it in my patch. If you dont like the patch, I'm open to
On Fri, 17 Apr 2020, Jason Gunthorpe wrote:
> On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote:
>> On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote:
>> > I tried to fix up some dependencies after the sii8620 "imply EXTCON"
>> > statementn broke, trying a few things but
On Fri, 17 Apr 2020, Sam Ravnborg wrote:
> Hi Arnd.
>
> On Fri, Apr 17, 2020 at 05:55:52PM +0200, Arnd Bergmann wrote:
>> Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
>> make any driver that needs it have a dependency on the class device
>> being available, to
On Fri, 17 Apr 2020, kgu...@codeaurora.org wrote:
> On 2020-04-15 20:39, Rob Herring wrote:
> > On Tue, Apr 07, 2020 at 09:17:07PM +0530, Kiran Gunda wrote:
> > > Convert the qcom-wled bindings from .txt to .yaml format.
> > > Also replace PM8941 to WLED3 and PMI8998 to WLED4.
> > >
> > >
igt_ppgtt_pin_update() invokes i915_gem_context_get_vm_rcu(), which
returns a reference of the i915_address_space object to "vm" with
increased refcount.
When igt_ppgtt_pin_update() returns, "vm" becomes invalid, so the
refcount should be decreased to keep refcount balanced.
The reference
> The "if(!encoder)" branch return the same value 0 of the success
> branch, maybe return -EINVAL is more better.
I suggest to improve the commit message.
* Would you like to adjust the patch subject?
* How do you think about to add the tag “Fixes”
because of adjustments for the exception
> kvfree ensure that the null pointer will do nothing.
I suggest to improve the commit message.
Would you like to adjust the patch subject?
Are you looking for further questionable condition checks?
…
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -98,8 +98,7 @@ static int
发件人：Markus Elfring
发送日期：2020-04-19 02:18:06
收件人：Bernard Zhao ,Alex Deucher
,"Christian König"
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org
抄送人："Felix Kühling"
,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com,Chunming
Zhou ,Daniel Vetter ,David Airlie
主题：Re:
Add binding document for the Chrontel CH7033 VGA/DVI/HDMI Encoder.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v3:
- Fixed the example so that it validates
Changes since v1:
- Dual licensed with BSD-2-Clause
- Collected Rob's reviewed-by tag
> There is no need to if check again,
Thanks for this information.
* Should the function name be mentioned in this change description?
* Would you like to adjust the patch subject?
> maybe we could merge into the above else branch.
I suggest to reconsider this wording.
…
> +++
In some case, like a DRM display code for example, it's useful to silently
check whether port node exists at all in a device-tree before proceeding
with parsing the graph.
This patch adds of_graph_get_local_port() which returns pointer to a local
port node, or NULL if graph isn't specified in a
发件人：Markus Elfring
发送日期：2020-04-19 17:34:47
收件人：Bernard Zhao
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,Alex
Deucher ,"Christian König"
,Chunming Zhou
抄送人：Andrzej Pietrasiewicz ,Daniel Vetter
,David Airlie ,Dhinakaran Pandiyan
,"José Roberto de Souza"
,Lyude Paul
Newer Tegra device-trees will specify a video output graph which involves
a bridge. This patch adds initial support for the DRM bridges to the Tegra
DRM output.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/drm.h| 2 ++
drivers/gpu/drm/tegra/output.c | 12
2 files
17.04.2020 23:58, Laurent Pinchart пишет:
> Hi Dmitry,
>
> On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 23:31, Laurent Pinchart пишет:
>>> On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
17.04.2020 22:30, Laurent Pinchart пишет:
...
Newer Tegra device-trees will specify a video output graph, which involves
LVDS encoder bridge. This patch adds support for the LVDS encoder bridge
to the RGB output, allowing us to model the display hardware properly.
Reviewed-by: Laurent Pinchart
Signed-off-by: Dmitry Osipenko
---
1 - 100 of 123 matches
Mail list logo
