On Mon, 01 Jul 2019, Sekhar Nori wrote:
> Hi Lee, Daniel, Jingoo,
>
> On 25/06/19 10:04 PM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > This is another small step on the path to liberating davinci from legacy
> > GPIO API calls and shrinking the davinci GPIO driver by not h
https://bugs.freedesktop.org/show_bug.cgi?id=111040
Andre Klapper changed:
What|Removed |Added
Component|DRM/other |Two
Group|
On Fri, 28 Jun 2019 09:30:22 -0300
Mauro Carvalho Chehab wrote:
> There are lots of documents under Documentation/*.txt and a few other
> orphan documents elsehwere that belong to the driver-API book.
>
> Move them to their right place.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
(...)
> .
https://bugs.freedesktop.org/show_bug.cgi?id=111040
Bug ID: 111040
Summary: it is not working
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Hi,
> > But the new and the old ones are identical, right? So why add/remove?
> > Why not just rename them?
>
> Hmm, OK. Does that somehow make a difference (e.g., easier backporting
> or maintenance)?
Easier patch review (it is obvious then you only change the way the
functions are hooked up
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the drm subsystem.
On Mon, Jun 24, 2019 at 6:24 AM Ville Syrjälä
wrote:
>
> On Fri, Jun 21, 2019 at 08:41:04PM -0700, Derek Basehore wrote:
> > Not every platform needs quirk detection for panel orientation, so
> > split the drm_connector_init_panel_orientation_property into two
> > functions. One for platforms with
On Mon, Jul 1, 2019 at 11:04 AM Gurchetan Singh
wrote:
>
>
>
> On Fri, Jun 28, 2019 at 5:14 AM Gerd Hoffmann wrote:
> >
> > Use gem reservation helpers and direct reservation_object_* calls
> > instead of ttm.
> >
> > v5: fix fencing (Chia-I Wu).
> > v3: Due to using the gem reservation object it
https://bugs.freedesktop.org/show_bug.cgi?id=108309
Francisco Pina Martins changed:
What|Removed |Added
CC||f.pinamart...@gmail.com
--- Co
On Mon, Jul 1, 2019 at 2:45 PM Laura Abbott wrote:
>
> On 6/24/19 3:49 PM, John Stultz wrote:
> > Here is another pass at the dma-buf heaps patchset Andrew and I
> > have been working on which tries to destage a fair chunk of ION
> > functionality.
> >
>
> I've gotten bogged down with both work an
On 6/24/19 3:49 PM, John Stultz wrote:
Here is another pass at the dma-buf heaps patchset Andrew and I
have been working on which tries to destage a fair chunk of ION
functionality.
I've gotten bogged down with both work and personal tasks
so I haven't had a chance to look too closely but, onc
Hi Colin,
Reviewed-by: Deepak Rawat
Thanks,
Deepak
On Mon, 2019-06-24 at 23:44 +0100, Colin King wrote:
> From: Colin Ian King
>
> Variable sub_res is initialized to a value that is never read and it
> is re-assigned later in a for-loop. The initialization is redundant
> and can be removed.
On Fri, Jun 28, 2019 at 04:53:02PM +0200, Timur Kristóf wrote:
> On Fri, 2019-06-28 at 17:14 +0300, Mika Westerberg wrote:
> > On Fri, Jun 28, 2019 at 03:33:56PM +0200, Timur Kristóf wrote:
> > > I have two more questions:
> > >
> > > 1. What is the best way to test that the virtual link is indeed
On Mon, Jul 01, 2019 at 10:46:34AM -0400, Alex Deucher wrote:
> > 2. As far as I understood what Mika said, there isn't really a 2.5 GT/s
> > limitation there, since the virtual link should be running at 40 Gb/s
> > regardless of the reported speed of that device. Would it be possible
> > to run th
> > > > Like I said the device really is limited to 2.5 GT/s even
> > > > though it
> > > > should be able to do 8 GT/s.
> > >
> > > There is Thunderbolt link between the host router (your host
> > > system)
> > > and
> > > the eGPU box. That link is not limited to 2.5 GT/s so even if the
> > > sl
> >
> > That's unfortunate, I would have expected there to be some sort of
> > PCIe
> > speed test utility.
> >
> > Now that I gave it a try, I can measure ~20 Gbit/sec when I run
> > Gnome
> > Wayland on this system (which forces the eGPU to send the
> > framebuffer
> > back and forth all the ti
Hi Thomas,
Thank you for your comments. Please see inline.
W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze:
Hi
I like the idea, but would prefer a more structured approach.
Setting connector->ddc before calling drm_sysfs_connector_add() seems
error prone. The dependency is not really clear
On Mon, 2019-07-01 at 16:54 +0200, Michel Dänzer wrote:
> On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
> > I haven't found a good way to measure the maximum PCIe throughput
> > between the CPU and GPU,
>
> amdgpu.benchmark=3
>
> on the kernel command line will measure throughput for various
> tr
On Thu, 2019-06-27 at 22:21 +, Li, Sun peng (Leo) wrote:
> Sorry for the late response! just jumping back on this now.
>
> On 2019-05-16 5:40 p.m., Lyude Paul wrote:
> > [CAUTION: External Email]
> >
> > So a couple of things:
> >
> > On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wro
On Mon, Jul 1, 2019 at 1:45 PM Rob Clark wrote:
>
> On Mon, Jul 1, 2019 at 10:39 AM Jeffrey Hugo wrote:
> >
> > Creating the msm gem address space requires a reference to the dev where
> > the iommu is located. The driver currently assumes this is the same as
> > the platform device, which break
On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo wrote:
>
> When assigning a mixer, we will iterate through the entire list looking for
> a suitable match. This results in selecting the last match. We should
> stop at the first match, since lower numbered mixers will typically have
> more capabiliti
Sorry for the late response! I like the idea here and I've brought up edid
comparison a couple times. Hopefully this isn't overkill, but I had a little
more in mind then just a helper like this (and I've had this on my mind for a
while!
When it comes to suspend/resume reprobing, I think there's mo
On Mon, Jul 1, 2019 at 10:45 AM Jeffrey Hugo wrote:
>
> Add support for MDP5 version v3.0 found on msm8998.
>
> Signed-off-by: Jeffrey Hugo
> ---
>
> 8998 support could probably be MDP5 or DPU. This MDP5 support works,
> but may not support all of the features that 8998 supports. However,
> DPU
On Mon, Jul 1, 2019 at 10:39 AM Jeffrey Hugo wrote:
>
> Creating the msm gem address space requires a reference to the dev where
> the iommu is located. The driver currently assumes this is the same as
> the platform device, which breaks when the iommu is outside of the
> platform device. Use th
On Mon, Jul 1, 2019 at 12:07 PM Jeffrey Hugo wrote:
>
> On 7/1/2019 12:58 PM, Rob Clark wrote:
> > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
> >>
> >> On 6/30/2019 9:01 AM, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Do an extra enable/disable cycle at init, to get the clks into
On 7/1/2019 12:58 PM, Rob Clark wrote:
On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
On 6/30/2019 9:01 AM, Rob Clark wrote:
From: Rob Clark
Do an extra enable/disable cycle at init, to get the clks into disabled
state in case bootloader left them enabled.
In case they were already en
On Mon, Jul 1, 2019 at 11:25 AM Eric Anholt wrote:
>
> Rob Clark writes:
>
> > From: Rob Clark
> >
> > The goal here is to support inheriting a display setup by bootloader,
> > although there may also be some non-display related use-cases.
> >
> > Rough idea is to add a flag for clks and power d
On Tue, Jun 25, 2019 at 8:07 PM Maxime Ripard wrote:
>
> On Mon, Jun 24, 2019 at 09:32:11PM +0530, Jagan Teki wrote:
> > On Mon, Jun 24, 2019 at 6:34 PM Maxime Ripard
> > wrote:
> > >
> > > On Fri, Jun 14, 2019 at 05:33:23PM +0530, Jagan Teki wrote:
> > > > On Thu, Jun 13, 2019 at 7:28 PM Maxime
On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
>
> On 6/30/2019 9:01 AM, Rob Clark wrote:
> > From: Rob Clark
> >
> > Do an extra enable/disable cycle at init, to get the clks into disabled
> > state in case bootloader left them enabled.
> >
> > In case they were already enabled, the clk_pre
On 6/30/2019 9:01 AM, Rob Clark wrote:
From: Rob Clark
Request the enable gpio ASIS to avoid disabling bridge during probe, if
already enabled. And if already enabled, defer enabling runpm until
attach to avoid cutting off the power to the bridge.
Once we get to attach, we know panel and drm
On 6/30/2019 9:01 AM, Rob Clark wrote:
From: Rob Clark
Do an extra enable/disable cycle at init, to get the clks into disabled
state in case bootloader left them enabled.
In case they were already enabled, the clk_prepare_enable() has no real
effect, other than getting the enable_count/prepare
On Sun, Jun 30, 2019 at 9:03 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Prep work for the following patch.
>
> Signed-off-by: Rob Clark
Reviewed-by: Jeffrey Hugo
Rob Clark writes:
> From: Rob Clark
>
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and which
On Sun, Jun 30, 2019 at 9:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Mark power domains that may be enabled by bootloader, and which should
> not be disabled until a driver takes them over.
>
> This keeps efifb alive until the real driver can be probed. In a distro
> kernel, the driver will
On Fri, Jun 28, 2019 at 5:14 AM Gerd Hoffmann wrote:
>
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> v5: fix fencing (Chia-I Wu).
> v3: Due to using the gem reservation object it is initialized and ready
> for use before calling ttm_bo_init, so we can al
On Sun, Jun 30, 2019 at 9:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enable
Add support for MDP5 version v3.0 found on msm8998.
Signed-off-by: Jeffrey Hugo
---
8998 support could probably be MDP5 or DPU. This MDP5 support works,
but may not support all of the features that 8998 supports. However,
DPU seems to only support 845 (MDP v4.0) with fundamental assumptions
ab
When assigning a mixer, we will iterate through the entire list looking for
a suitable match. This results in selecting the last match. We should
stop at the first match, since lower numbered mixers will typically have
more capabilities, and are likely to be what the bootloader used, if we
are lo
Creating the msm gem address space requires a reference to the dev where
the iommu is located. The driver currently assumes this is the same as
the platform device, which breaks when the iommu is outside of the
platform device. Use the drm_device instead, which happens to always have
a reference
Hi,
On Sun, Jun 30, 2019 at 1:03 PM Sam Ravnborg wrote:
>
> Hi Douglas.
>
> Some long overdue review feedback.
>
> On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > From: Sean Paul
> >
> > This patch adds a new subnode to simple-panel allowing us to override
> > the typical t
On Mon, 1 Jul 2019 at 13:37, Emil Velikov wrote:
>
> Hi Fuqian,
>
> On Mon, 1 Jul 2019 at 08:13, Fuqian Huang wrote:
> >
> > Using dev_get_drvdata directly.
> >
> > Signed-off-by: Fuqian Huang
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> > drivers/gpu/drm/msm/disp/
Hi,
On Fri, Jun 28, 2019 at 09:34:52AM +0100, Daniel Thompson wrote:
> On Wed, Jun 26, 2019 at 04:56:11PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > Export the type of the brightness curve via the new sysfs attribute
> > > 'scale'. The value of the attribute may be a simple string like
> > > 'l
Hi,
On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg wrote:
>
> > @@ -91,6 +92,8 @@ struct panel_simple {
> > struct i2c_adapter *ddc;
> >
> > struct gpio_desc *enable_gpio;
> > +
> > + struct drm_display_mode override_mode;
> I fail to see where this poiter is assigned.
In panel_sim
Hi,
On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg wrote:
>
> Hi Douglas.
>
> > > +
> > > + /* Only add timings if override was not there or failed to validate */
> > > + if (num == 0 && panel->desc->num_timings)
> > > + num = panel_simple_get_timings_modes(panel);
> > > +
> > > + /
https://bugs.freedesktop.org/show_bug.cgi?id=107990
John changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Jul 01, 2019 at 11:22:35AM +0800, Fuqian Huang wrote:
> Using dev_get_drvdata directly.
msm parts LGTM. If you split the patches feel free to add my
Acked-by: Jordan Crouse
> Signed-off-by: Fuqian Huang
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> drivers/gp
JJ
On 7/1/19 10:14 AM, Jean-Jacques Hiblot wrote:
Update the led binding to describe the possibility to add a "compatible"
option to create a child-device, user of the LED.
Signed-off-by: Jean-Jacques Hiblot
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/leds/common.txt
This series aims to add a led-backlight driver, similar to pwm-backlight,
but using a LED class device underneath.
A few years ago (2015), Tomi Valkeinen posted a series implementing a
backlight driver on top of a LED device:
https://patchwork.kernel.org/patch/7293991/
https://patchwork.kernel.org
From: Tomi Valkeinen
Add DT binding for led-backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
Cc: devicet...@vger.kernel.org
---
.../video/backlight/led-backlight.txt | 39 +++
1 file changed, 39 insertions(+)
create mode 100644
Documentatio
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is mostly similar to
pwm_bl except the driver uses a LED class driver to adjust the brightness
in the HW.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
---
drivers/video/backlight/Kconfig | 7 +
This allows the LED core to probe a consumer device when the LED is
registered. In that way the LED can be seen like a minimalist bus that
can handle at most one device.
This is useful to manage simple devices, the purpose of which is
mostly to drive a LED.
One example would be a LED-controlled ba
Update the led binding to describe the possibility to add a "compatible"
option to create a child-device, user of the LED.
Signed-off-by: Jean-Jacques Hiblot
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/leds/common.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 7/1/19 10:37 AM, Benjamin Tissoires wrote:
> Hi Bartlomiej,
Hi Benjamin,
> On Fri, Jun 14, 2019 at 4:52 PM Bartlomiej Zolnierkiewicz
> wrote:
>>
>> framebuffer_alloc() can fail only on kzalloc() memory allocation
>> failure and since kzalloc() will print error message in such case
>> we can
Hi,
On 28-06-19 13:51, Maxime Ripard wrote:
On Fri, Jun 28, 2019 at 12:04:30PM +0200, Hans de Goede wrote:
Hi all,
On 24-06-19 17:40, Hans de Goede wrote:
Hi All,
Good news I have a contact inside GPD now and from now on their BIOS-es
will have proper sys_vendor and product_name DMI strings.
On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
>
> I haven't found a good way to measure the maximum PCIe throughput
> between the CPU and GPU,
amdgpu.benchmark=3
on the kernel command line will measure throughput for various transfer
sizes during driver initialization.
> but I did take a look
On Mon, Jul 1, 2019 at 10:38 AM Timur Kristóf wrote:
>
> > > > > Like I said the device really is limited to 2.5 GT/s even
> > > > > though it
> > > > > should be able to do 8 GT/s.
> > > >
> > > > There is Thunderbolt link between the host router (your host
> > > > system)
> > > > and
> > > > the
Hi
Am 01.07.19 um 10:48 schrieb Gerd Hoffmann:
> On Mon, Jul 01, 2019 at 09:28:59AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 01.07.19 um 08:32 schrieb Gerd Hoffmann:
>>> On Fri, Jun 28, 2019 at 02:26:56PM +0200, Thomas Zimmermann wrote:
PRIME functionality is now provided via the callba
On Mon, Jul 1, 2019 at 7:03 AM Rob Herring wrote:
>
> On Sun, Jun 30, 2019 at 2:36 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > The panel-id property in chosen can be used to communicate which panel,
> > of multiple possibilities, is installed.
> >
> > Signed-off-by: Rob Clark
> > ---
>
Hi Lee, Daniel, Jingoo,
On 25/06/19 10:04 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This is another small step on the path to liberating davinci from legacy
> GPIO API calls and shrinking the davinci GPIO driver by not having to
> support the base GPIO number anymore.
>
> T
Hi
Am 01.07.19 um 15:27 schrieb Andrzej Pietrasiewicz:
> Hi Thomas,
>
> Thank you for your comments. Please see inline.
>
> W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze:
>> Hi
>>
>> I like the idea, but would prefer a more structured approach.
>>
>> Setting connector->ddc before calling dr
On 7/1/2019 8:03 AM, Rob Herring wrote:
On Sun, Jun 30, 2019 at 2:36 PM Rob Clark wrote:
From: Rob Clark
The panel-id property in chosen can be used to communicate which panel,
of multiple possibilities, is installed.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/chosen.
On Sun, Jun 30, 2019 at 2:27 PM Timur Kristóf wrote:
>
>
> > > Sure, though in this case 3 of those downstream ports are not
> > > exposed
> > > by the hardware, so it's a bit surprising to see them there.
> >
> > They lead to other peripherals on the TBT host router such as the TBT
> > controller
On Sun, Jun 30, 2019 at 2:36 PM Rob Clark wrote:
>
> From: Rob Clark
>
> The panel-id property in chosen can be used to communicate which panel,
> of multiple possibilities, is installed.
>
> Signed-off-by: Rob Clark
> ---
> Documentation/devicetree/bindings/chosen.txt | 69
Good evening from Singapore,
May I know what is Direct Rendering Infrastructure (DRI)?
Thank you.
-BEGIN EMAIL SIGNATURE-
The Gospel for all Targeted Individuals (TIs):
[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers
Link:
https://www.nytimes.
Hi Jerry,
On Thu, 25 Apr 2019 at 08:40, Jerry Han wrote:
>
> Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> panel.
>
> V8:
> - Modify communication address
>
> V7:
> - Add the information of the reviewer
> - Remove unnecessary delays, The udelay_range code gracefully retu
Hi Fuqian,
Thank you for the pach.
On Mon, Jul 01, 2019 at 11:22:35AM +0800, Fuqian Huang wrote:
> Using dev_get_drvdata directly.
This could be expanded a bit. Maybe
"Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata(). Thes
Hi Fuqian,
On Fri, 28 Jun 2019 at 09:30, Fuqian Huang wrote:
>
> zalloc has already zeroed the memory.
> so memset is unneeded.
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 2 --
> drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0
Hi Fuqian,
On Mon, 1 Jul 2019 at 08:13, Fuqian Huang wrote:
>
> Using dev_get_drvdata directly.
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
> drivers/gpu/drm/msm/disp/m
On 01.07.2019 11:58, Maxime Ripard wrote:
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
>> On 12.06.2019 17:20, Maxime Ripard wrote:
I am not sure if I understand whole discussion here, but I also do not
understand whole edp-connector thing.
>>> The context is t
https://bugs.freedesktop.org/show_bug.cgi?id=107877
Andre Klapper changed:
What|Removed |Added
URL|https://routerloginnet.tips |
|/
Hi all,
After merging the hmm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
mm/hmm.c: In function 'hmm_get_or_create':
mm/hmm.c:50:2: error: implicit declaration of function
'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'?
[-Werror=implicit-func
https://bugs.freedesktop.org/show_bug.cgi?id=111010
e88z4 changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Sun, 23 Jun 2019 at 11:36, Sam Ravnborg wrote:
> -int mga_driver_fence_wait(struct drm_device *dev, unsigned int *sequence)
> +void mga_driver_fence_wait(struct drm_device *dev, unsigned int *sequence)
> {
> drm_mga_private_t *dev_priv = (drm_mga_private_t *) dev->dev_private;
>
On Sun, 30 Jun 2019 at 07:20, Sam Ravnborg wrote:
>
> Drop the deprecated drmP.h header file.
>
> Made the header file selfcontained, and dropped unused header files.
> Fixed fallout in remaining files.
>
> Signed-off-by: Sam Ravnborg
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> C
On 27.06.2019 17:18, Matt Redfearn wrote:
> In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
> which attach to the DSI host via mipi_dsi_attach() at probe time, the
> ADV7533 bridge device does not. Instead it defers this to the point that
> the upstream device connects to its b
On 27.06.2019 10:59, Lucas Stach wrote:
> To get the chip into the expected state, even when the hardware reset pin
> isn't connected, do a software reset in this case. It isn't as thorough as
> the hardware reset, as the I2C communication block can not be reset for
> obvious reasons, but it's gett
On 12.06.2019 10:51, Neil Armstrong wrote:
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on Amlogic, Allwinner and Roc
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder spinlock should be initialized during dpu encoder
init instead of dpu encoder setup which is part
Hi!
On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> On 12.06.2019 17:20, Maxime Ripard wrote:
> >> I am not sure if I understand whole discussion here, but I also do not
> >> understand whole edp-connector thing.
> > The context is this one:
> > https://patchwork.freedesktop.org/p
Hi Daniel, hi Dave,
please pull in this fix, which fixes a kernel nullptr deref on module
unload when any etnaviv GPU failed to initialize properly.
Regards,
Lucas
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are avail
https://bugs.freedesktop.org/show_bug.cgi?id=107877
--- Comment #28 from rozersamith ---
mywifiexxt.net a one stop solution shop for all your queries related to Netgear
WiFi Extender Setup and Netgear Login issues. Get in touch will the leading
technical experts, who are eager to provide you with
On 01.07.2019 11:23, Andrzej Hajda wrote:
> On 01.07.2019 05:39, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> A single driver should not enable (select) an entire subsystem,
>> such as INPUT, so change the 'select' to "depends on".
>>
>> Fixes: d6abe6df706c ("drm/bridge: sil_sii8620: do not hav
On 01.07.2019 05:39, Randy Dunlap wrote:
> From: Randy Dunlap
>
> A single driver should not enable (select) an entire subsystem,
> such as INPUT, so change the 'select' to "depends on".
>
> Fixes: d6abe6df706c ("drm/bridge: sil_sii8620: do not have a dependency of
> RC_CORE")
>
> Signed-off-by:
On Sun, Jun 30, 2019 at 07:21:31AM +0200, Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
>
> While touching the list of include files divide them
> into blocks and sort within each block.
> Fix fallout.
>
> Signed-off-by: Sam Ravnborg
> Cc: Liviu Dudau
Acked-by: Liviu Dud
Le dim. 30 juin 2019 à 08:19, Sam Ravnborg a écrit :
>
> Drop use of the deprecated header file drmP.h
> from the sole user in the stm driver.
> Replace with necessary include files.
Applied on drm-misc-next.
Thanks,
Benjamin
>
> Signed-off-by: Sam Ravnborg
> Cc: Yannick Fertre
> Cc: Philippe
On Mon, Jul 01, 2019 at 09:28:59AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 01.07.19 um 08:32 schrieb Gerd Hoffmann:
> > On Fri, Jun 28, 2019 at 02:26:56PM +0200, Thomas Zimmermann wrote:
> >> PRIME functionality is now provided via the callback functions in
> >> struct drm_gem_object_funcs. Th
On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
> Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
> but it turns out that because we didn't filter valid gfp_t flags
> on the DMA allocator, a bunch of drivers were passing __GFP_COMP
> to it, which is rather bo
Hi Bartlomiej,
On Fri, Jun 14, 2019 at 4:52 PM Bartlomiej Zolnierkiewicz
wrote:
>
> framebuffer_alloc() can fail only on kzalloc() memory allocation
> failure and since kzalloc() will print error message in such case
> we can omit printing extra error message in drivers (which BTW is
> what the m
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/i915/display/intel_dp.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/displ
Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.
The 'subconnector' property is already utilized for DVI-
On Fri, Jun 28, 2019 at 02:16:45PM +0200, Arnd Bergmann wrote:
> Putting a large drm_connector object on the stack can lead to warnings
> in some configuration, such as:
>
> drivers/gpu/drm/selftests/test-drm_cmdline_parser.c:18:12: error: stack frame
> size of 1040 bytes in function 'drm_cmdline_
Hi
Am 01.07.19 um 08:32 schrieb Gerd Hoffmann:
> On Fri, Jun 28, 2019 at 02:26:56PM +0200, Thomas Zimmermann wrote:
>> PRIME functionality is now provided via the callback functions in
>> struct drm_gem_object_funcs. The driver-structure functions are obsolete.
>> As a side effect of this patch, V
On (06/19/19 02:07), Ilia Mirkin wrote:
> If all else fails, just remove nouveau_dri.so and/or boot with
> nouveau.noaccel=1 -- should be perfect.
nouveau.noaccel=1 did the trick. Is there any other, let's say
less CPU-intensive, way to fix nouveau?
-ss
___
These v2 patches incorporate the following changes
1/2 dt-bindings: backlight:
The documentation for "arc" has been re-added but marked (deprecated)
to match the actual driver support for that
2/2 backlight: arcxcnn:
Added new-lines and fixed spelling as per feedback
Original patch description
Using dev_get_drvdata directly.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c| 6 ++
drivers/gpu/drm/msm/dsi/dsi_host.c
In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomic_helper_connector_reset(),
where newly allocated asyc->state will be assigned to
The vendor-prefixes.txt file properly refers to ArcticSand
as arctic but the driver bindings improperly abbreviated the
prefix to arc. This was a mistake in the original patch. This
patch adds "arctic" and retains "arc" (deprecated) bindings
Signed-off-by: Brian Dodge
---
.../bindings/leds/backl
The original patch adding this driver and DT bindings improperly
used "arc" as the vendor-prefix. This adds "arctic" which is the
proper prefix and retains "arc" to allow existing users of the
"arc" prefix to update to new kernels. There is at least one
(Samsung Chromebook Plus)
Signed-off-by: Bri
From: Randy Dunlap
A single driver should not enable (select) an entire subsystem,
such as INPUT, so change the 'select' to "depends on".
Fixes: d6abe6df706c ("drm/bridge: sil_sii8620: do not have a dependency of
RC_CORE")
Signed-off-by: Randy Dunlap
Cc: Inki Dae
Cc: Andrzej Hajda
Cc: Laure
Hi,
This is a duplicated patchset and please ignore this.
The latest changes for power management have been committed at:
https://patchwork.freedesktop.org/series/62181/
Sorry for the inconvenience.
Best regards,
Lowry
On Fri, Jun 21, 2019 at 03:57:29PM +0800, Lowry Li (Arm Technology China) wr
100 matches
Mail list logo
