It looks like that this GPU core triggers an abort when
reading VIVS_HI_CHIP_PRODUCT_ID and/or VIVS_HI_CHIP_ECO_ID.
I looked at different versions of Vivante's kernel driver and did
not found anything about this issue or what feature flag can be
used. So go the simplest route and do not read
On Sun, Aug 16, 2020 at 11:20:41AM +0530, Vinay Simha BN wrote:
> passing zero to 'PTR_ERR'
>
> Reported-by: kernel test robot
> Signed-off-by: Vinay Simha BN
Applied to drm-misc-next - thanks.
Sam
> ---
> drivers/gpu/drm/bridge/tc358775.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Update backlight implementation to utilize newly added backlight
functionality.
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
- Moved enable/disable after registering backlight device
One side-effect of these changes is that the
- Use get/set methods for backlight_properties
- Use macro for backlight initialization
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: linux-renesas-...@vger.kernel.org
---
.../gpu/drm/shmobile/shmob_drm_backlight.c| 20 +++
1 file changed, 7
- Use backlight support from drm_panel.
This shifts this driver away from manually handling of power state.
- Add helper function for registering backlight, like other samsung
panel drivers do.
- Use devm_ for backlight register thus benefit from automatic
unregistering. Drop all explicit
- Use backlight support from drm_panel.
This shifts this driver away from manually handling of power state.
- Add helper function for registering backlight, like other samsung
panel drivers do.
- Register backlight driver after drm_panel_init
- Use devm_ for backlight register thus benefit
Use dev_err_probe() to make some of the error handling
simpler in the probe function.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/gpio_backlight.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
- Use get method to read brightness
- Use drm_panel support for backlight
- This drops enable/disable operations as they are no longer needed.
The enable/disable operations had some backlight related comments
that are no longer valid. The only correct way to enable/disable
backlight
Update backlight to use macro for initialization and the
backlight_get_brightness() operation to simply the update operation.
Use the drm_panel backlight functionality, which allowed the
deletion of the enable and disable functions.
Moved init of backlight device so it comes after
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/atombios_encoders.c| 24 +--
Add get and set operations to incapsualte access to backlight brightness.
One easy win is that the get/set operations can be used when backlight
is not included in the configuration, resulting in simpler code with
less ifdef's and thus more readable code.
The backlight_enable_brightness() update
- Replace direct access to backlight_properties with
backlight_get_brightness().
- Use macro for initialization
Signed-off-by: Sam Ravnborg
Cc: Robert Chiras
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 11 +++
1 file changed, 3
- Use drm_panel backlight support
- Use macro for backlight initialization
Signed-off-by: Sam Ravnborg
Cc: Paweł Chmiel
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 25 +++
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git
backlight_update_status() may be called from code that does not have
any valid backlight device. To avoid ifdeffery and too much conditionals
silently fail if the backlight_device is NULL.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
Update backlight to use macro for initialization and the
backlight_get_brightness() operation to simply the update operation.
Signed-off-by: Sam Ravnborg
Cc: Konrad Dybcio
Cc: Thierry Reding
Cc: Sam Ravnborg
---
.../gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 15 +++
1 file
Introduce use of DECLARE_BACKLIGHT_INIT_RAW when registering the
backlight.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/gpio_backlight.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
- Use backlight_get_brightness() helper
- Use backlight_is_blank() helper
- Use macro for initialization
- Drop direct access to backlight properties
- Use the devm_ variant for registering backlight device, and drop
all explicit unregistering of the backlight device.
- Register backligt after
Introduce backlight_{enable,disable} to enable/disable backlight.
Dropped NULL check as backlight_{enable,disable} handles this.
Signed-off-by: Sam Ravnborg
Cc: Rob Clark
Cc: Ezequiel Garcia
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 9 -
1 file
Use backlight_{enable,disable} in the probe function to
avoid hardcoding power handling in the driver.
Move platform_set_drvdata() up as the enable/disable call
will trigger a callback to the driver.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
The backlight support is updated to utilise newly added macros and
functions thus simplifying the code.
- Introduced backlight_set_brightness() that can be called with a
NULL backlight_device
- backlight_update_status() can be called with a NULL backlight_device.
Benefit from this by removing
The first patch trims backlight_update_status() so it can be called with a NULL
backlight_device. Then the caller do not need to add this check just to avoid
a NULL reference.
The backlight drivers uses several different patterns when registering
a backlight:
- Register backlight and assign
- Replace direct access to backlight_properties with
backlight_get_brightness().
- Use brightness and not power to determine if backlight is off
- Use the devm_ variant for registering backlight device, and drop
all explicit unregistering of the backlight device.
Signed-off-by: Sam Ravnborg
Device registration almost always uses a struct backlight_properties
variable to pass config info. Make it simpler and less error prone
by the introduction of a number of macros.
There is one macro for each type of backlight {firmware, platform, raw}.
All members in struct backlight_properties
- Replace direct access to backlight_properties with
backlight_get_brightness().
- Drop debug printout
- Use macro for initialization
Signed-off-by: Sam Ravnborg
Cc: Linus Walleij
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 9 +++--
1 file
- Introduce backlight_{enable/disable)
- Use get/set methods for backlight_properties
- Drop redundant get_brightness() implementation
The default implementation return the current brightness value
- Use macro for backlight initialization
v2:
- Drop backlight_update() call as it is redundant
- Use blacklight_get_brightness() helper
- Use devm_ variant to register backlight device and drop explicit
unregister
- Use macro for initialization
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Cc: Sam Ravnborg
---
.../gpu/drm/amd/amdgpu/atombios_encoders.c| 19
Hi Nadezda
On Wed, Aug 19, 2020 at 05:37:56PM +0300, Nadezda Lutovinova wrote:
> If ge_b850v3_lvds_init() does not allocate memory for ge_b850v3_lvds_ptr,
> then a null pointer dereference is accessed.
>
> The patch adds checking of the return value of ge_b850v3_lvds_init().
>
> Found by Linux
On Sun, Aug 23, 2020 at 09:10:25PM +0200, Christian Gmeiner wrote:
> Hi
>
> > I have formally tested the patch with 5.7.10 - and it doesn't resolve
> > the issue - sadly :(
> >
> > From my testing, the reads on
> > VIVS_HI_CHIP_PRODUCT_ID
> > VIVS_HI_CHIP_ECO_ID
> > need to be conditional - while
https://bugzilla.kernel.org/show_bug.cgi?id=208909
--- Comment #11 from ker...@890.at ---
Created attachment 292063
--> https://bugzilla.kernel.org/attachment.cgi?id=292063=edit
5.8.3 backtrace
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208909
--- Comment #10 from ker...@890.at ---
just tried the 5.8.3 kernel with the same result, backtrace is attached.
This time I tried to rotate the display on the DisplayPort/USB-C, it does not
seem to be related to the port.
--
You are receiving
Hi
> I have formally tested the patch with 5.7.10 - and it doesn't resolve
> the issue - sadly :(
>
> From my testing, the reads on
> VIVS_HI_CHIP_PRODUCT_ID
> VIVS_HI_CHIP_ECO_ID
> need to be conditional - while
> VIVS_HI_CHIP_CUSTOMER_ID
> seems to be okay.
>
Uhh.. okay.. just send a V2 -
Hello,
On Thu, Aug 20, 2020 at 04:38:18PM -0700, Hyun Kwon wrote:
> On Thursday, August 20, 2020 2:18 PM, Kenneth Sloat write:
> > Hello,
> >
> > The Xilinx Video mixer IP uses the DRM fourcc string as a device tree
> > binding in
> > order to describe the format for a specific DRM layer/plane.
Hi Qian,
On Fri, Aug 21, 2020 at 09:20:37PM -0400, Qian Cai wrote:
> On Mon, Jun 08, 2020 at 06:16:22AM +0300, Laurent Pinchart wrote:
> > Hi Qian,
> >
> > I forgot to mention, I think the subject line should be
> >
> > drm/rcar-du: Make DRM_RCAR_WRITEBACK depend on DRM_RCAR_DU
> >
> > Could
Hi Stefan,
On Fri, Aug 21, 2020 at 04:53:56PM +0200, Stefan Agner wrote:
> On 2020-08-13 03:29, Laurent Pinchart wrote:
> > Additional compatible strings have been added in DT source for the
> > i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
> > Most of the upstream DT
Hi Stefan,
On Fri, Aug 21, 2020 at 04:55:38PM +0200, Stefan Agner wrote:
> On 2020-08-13 03:29, Laurent Pinchart wrote:
> > Rename the mxsfb.yaml binding schema to fsl,lcdif.yaml to match the
> > usual bindings naming scheme.
>
> I tend to prefer to just name it fsl,lcdif.yaml from the get-go.
>
Hi Tomi,
On Fri, Aug 14, 2020 at 12:29:35PM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
>
> >> +static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
> >> +{
> >> + int ret, full;
> >> +
> >> + WARN_ON(!mutex_is_locked(>mbox_mutex));
> >> +
>
https://bugzilla.kernel.org/show_bug.cgi?id=209017
Clément Guérin (li...@protonmail.com) changed:
What|Removed |Added
Regression|No |Yes
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=209017
Bug ID: 209017
Summary: [amdgpu] Black screen when unlocking session
Product: Drivers
Version: 2.5
Kernel Version: 5.8.2
Hardware: All
OS: Linux
Tree:
The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel. Commit
f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC
panel") has fixed the bus formats, but forgot to address the bpc value.
Set it to 6.
Fixes: f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC
Hi Prabhakar,
Thank you for the patch.
On Thu, Aug 13, 2020 at 03:00:41PM +0100, Lad Prabhakar wrote:
> The iwg21d comes with a 7" capacitive touch screen, therefore
> add support for it.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Everything seems to match the
Hi James,
On Sun, Aug 23, 2020 at 01:04:43PM -0700, James Jones wrote:
> On 8/20/20 1:15 AM, Ezequiel Garcia wrote:
> > On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote:
> >> On 8/17/20 8:18 AM, Brian Starkey wrote:
> >>> On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote:
>
https://bugzilla.kernel.org/show_bug.cgi?id=209015
Bug ID: 209015
Summary: Clocks are no longer reported for R9 390 GPU
Product: Drivers
Version: 2.5
Kernel Version: 5.8
Hardware: All
OS: Linux
Tree: Mainline
[AMD Official Use Only - Internal Distribution Only]
Thanks for fixing this. The patch is reviewed-by: Evan Quan
BR
Evan
-Original Message-
From: Randy Dunlap
Sent: Monday, August 24, 2020 6:36 AM
To: dri-devel ; LKML
; amd-...@lists.freedesktop.org; Deucher,
Alexander
Cc: Quan,
https://bugzilla.kernel.org/show_bug.cgi?id=209019
Bug ID: 209019
Summary: [drm:dpcd_set_source_specific_data [amdgpu]] *ERROR*
Error in DP aux read transaction, not writing source
specific data
Product: Drivers
On 8/20/20 1:15 AM, Ezequiel Garcia wrote:
On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote:
On 8/17/20 8:18 AM, Brian Starkey wrote:
Hi Ezequiel,
On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote:
This heap is basically a wrapper around DMA-API dma_alloc_attrs,
which will
On 8/23/20 1:46 PM, Laurent Pinchart wrote:
Hi James,
On Sun, Aug 23, 2020 at 01:04:43PM -0700, James Jones wrote:
On 8/20/20 1:15 AM, Ezequiel Garcia wrote:
On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote:
On 8/17/20 8:18 AM, Brian Starkey wrote:
On Sun, Aug 16, 2020 at 02:22:46PM
Hi Tomi,
On Fri, Aug 14, 2020 at 11:22:09AM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
>
> >> +static int cdns_mhdp_connector_init(struct cdns_mhdp_device *mhdp)
> >> +{
> >> + u32 bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
> >> + struct drm_connector *conn =
48 matches
Mail list logo
