Hi Vinay.
> +
> +static int tc_probe(struct i2c_client *client, const struct i2c_device_id
> *id)
> +{
> + struct device *dev = &client->dev;
> + struct drm_panel *panel;
> + struct tc_data *tc;
> + int ret;
> +
> + tc = devm_kzalloc(dev, sizeof(*tc), GFP_KERNEL);
> + if (
Hi Wei.
On Thu, Jun 18, 2020 at 01:46:50PM +, Wei Yongjun wrote:
> It's not necessary to unregister backlight device which
> registered with devm_backlight_device_register().
>
> Fixes: 12a6cbd4f3f1 ("drm/panel: otm8009a: Use new backlight API")
> Reported-by: Hulk Robot
> Signed-off-by: Wei
Hi Dmitry
On Thu, Jun 18, 2020 at 01:27:03AM +0300, Dmitry Osipenko wrote:
> The DRM panel bridge core requires connector type to be set up properly,
> otherwise it rejects the panel. The missing connector type problem popped
> up while I was trying to wrap CLAA070WP03XG panel into a DRM bridge in
Hi Gustavo.
On Wed, Jun 17, 2020 at 12:56:47PM -0500, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
>
Hi Sam and Dmitry,
On Sat, Jun 20, 2020 at 01:21:32PM +0200, Sam Ravnborg wrote:
> On Thu, Jun 18, 2020 at 01:27:03AM +0300, Dmitry Osipenko wrote:
> > The DRM panel bridge core requires connector type to be set up properly,
> > otherwise it rejects the panel. The missing connector type problem po
Hi All,
Here is v3 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to supp
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v3:
- Add Andy's Reviewed-by tag
- Remove extra whitespace to align some code after assignments (requested by
Uwe Kleine-König)
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Signed-off-by: Hans de Goede
---
drivers/gp
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input cl
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Signed-off-by: Hans de Goede
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
drivers/pwm/pwm-crc.c | 89 ++-
1 file chan
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
backlight-ena
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the m
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested f
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set i
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastse
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter ove
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consume
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clo
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which grea
https://bugzilla.kernel.org/show_bug.cgi?id=199475
DCWizard (andrea...@protonmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Re
Hi Dmitry
>
> Oops! Good catch!
Yep, thanks Laurent. Should have taken a better look before applying.
> Indeed, I blindly set the LVDS type to all these
> panels. Please revert this patch, I'll double check each panel and
> prepare an updated version of this patch. Thank you very much for the
>
Am 2020-06-20 um 9:21 a.m. schrieb Julia Lawall:
>
> On Sat, 20 Jun 2020, Markus Elfring wrote:
>
>>> The function kobject_init_and_add alloc memory like:
>>> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
>>> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
>>> ->k
Hi Dmitry
On Sat, Jun 20, 2020 at 06:05:37PM +0300, Dmitry Osipenko wrote:
> 20.06.2020 17:31, Sam Ravnborg пишет:
> > Hi Dmitry
> >
> >>
> >> Oops! Good catch!
> > Yep, thanks Laurent. Should have taken a better look before applying.
> >
> >> Indeed, I blindly set the LVDS type to all these
> >>
On Sat, Jun 20, 2020 at 3:26 AM Zenghui Yu wrote:
>
> ping for this obvious fix...
Hi, thanks, but there is already a similar fix in msm-next:
commit aa472721c8dbe1713cf510f56ffbc56ae9e14247
Refs: v5.7-rc5-33-gaa472721c8db
Author: Chen Tao
AuthorDate: Mon Jun 8 09:48:59 2020 +0800
Commit:
Hi Vinod.
Looks good but some some of small nits.
And a few larger things in the following.
The larger things is releated to prepare the bridge driver to live in a
world with chained bridges.
Sam
On Wed, Jun 17, 2020 at 04:29:50PM +0530, Vinod Koul wrote:
> Lontium Lt9611 is a DSI to HDM
https://bugzilla.kernel.org/show_bug.cgi?id=208179
Shlomo (shl...@fastmail.com) changed:
What|Removed |Added
Kernel Version|5.7.2 |5.7.2,5.7.4,5.8-rc1
--- Co
Hi Ricardo.
On Wed, Jun 17, 2020 at 11:46:29AM +0200, Ricardo Cañuelo wrote:
> This series converts the DT binding for the TI TFP410 DPI-to-DVI encoder
> to json-schema.
>
> It also fixes a minor bug in the ti-tfp410 driver that causes a
> wrong calculation of the setup and hold times when the de
On Mon, Jun 8, 2020 at 7:48 PM Douglas Anderson wrote:
> The kernel test robot noted that if "OF" is defined (which is needed
> to select DRM_TI_SN65DSI86 at all) but not OF_GPIO that we'd get
> compile failures because some of the members that we access in "struct
> gpio_chip" are only defined "
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200618]
[also build test ERROR on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7
v5.7-rc7]
[If your pat
On Wed, Jun 17, 2020 at 10:03:38AM +0200, Thomas Zimmermann wrote:
> The driver cannot suspend before it has loaded completely. So the test
> for device pointers is not required. Remove them.
>
> Signed-off-by: Thomas Zimmermann
Sounds resonable.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/
Hi Ondrej et al.
On Wed, Jun 17, 2020 at 02:32:07AM +0200, Ondrej Jirman wrote:
> From: Icenowy Zheng
>
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> Xingbangda, which is used on PinePhone final assembled phones.
>
> It is based on Sitronix ST7703 LCD controller.
I a
Hi Enric
On Mon, Jun 15, 2020 at 10:31:01PM +0200, Enric Balletbo i Serra wrote:
> (This resend is to fix some trivial conflicts due the merge window)
>
> The PS8640 dsi-to-eDP bridge driver is using the panel bridge API,
> however, not all the components in the chain have been ported to the
> dr
Hi Enric.
On Mon, Jun 15, 2020 at 10:53:20PM +0200, Enric Balletbo i Serra wrote:
> The get_edid() callback can be triggered anytime by an ioctl, i.e
>
> drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
> -> ps86
Convert the Renesas R-Car FDP1 text binding to YAML.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
- Update MAINTAINERS
---
.../bindings/media/renesas,fdp1.txt | 37 ---
.../bindings/media/renesas,fdp1.yaml | 63 +++
Convert the Renesas R-Car VSP1 text binding to YAML.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
- Simplify comments on compatible strings
- Update MAINTAINERS
---
.../bindings/media/renesas,vsp1.txt | 30 ---
.../bindings/media/renesas,v
The resets property is used in DT sources in the kernel tree. Document
it and make it mandatory.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
- Fix typo in commit message
---
Documentation/devicetree/bindings/media/renesas,fdp1.yaml | 5 +
1 file ch
This patch series converts the DT bindings for the Renesas R-Car FCP,
FDP1 and VSP1 to YAML. It also updates the bindings based on the
properties that have been added to the DT sources over time but never
documented.
Compared to v1, review comments have been incorporated to fix small
typos and sim
The power-domains and resets properties are used in all DT sources in
the kernel but are absent from the bindings. Document them and make them
mandatory.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
.../devicetree/bindings/media/renesas,vsp1.yaml| 14 ++
1
All DT source files in the kernel tree specify the power-domains
property. Make it mandatory.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
- Fix typo in commit message
---
Documentation/devicetree/bindings/media/renesas,fcp.yaml | 1 +
1 file changed, 1
All DT source files in the kernel tree specify the power-domains
property. Make it mandatory.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
- Fix typo in comment message
---
Documentation/devicetree/bindings/media/renesas,fdp1.yaml | 1 +
1 file changed,
The resets and iommus properties are used in DT sources in the kernel
tree. Document them, and make resets mandatory. The iommus property is
optional as not all platforms wire the FCP to a functional IOMMU.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
Documentation/device
Convert the Renesas R-Car FCP text binding to YAML.
Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
- Simplify comments on compatible strings
- Update MAINTAINERS
---
.../devicetree/bindings/media/renesas,fcp.txt | 34 ---
.../bindings/media/renesa
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20200618]
[also build test WARNING on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7
v5.7-rc7]
[If
Several DRM drivers uAPI headers that are licensed under the GPL carry
both an SPDX header and a copy of the license text. Drop the latter.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/armada_drm.h | 4
include/uapi/drm/etnaviv_drm.h | 12
include/uapi/drm/exynos_drm.
Most of the DRM drivers uAPI headers are licensed under the MIT license,
and carry copies of the license with slight variations. Replace them
with SPDX headers.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/amdgpu_drm.h | 19 +--
include/uapi/drm/i915_drm.h| 22 +-
The DRM core uAPI headers are licensed under the MIT license, and carry
copies of the license with slight variations. Replace them with SPDX
headers.
Following a discussion with Daniel Vetter on this topic, add a
clarification in the drm-uapi.rst file that independent closed-source
userspace imple
Hi Dave and Daniel,
Just one small fix for the R-Car DU driver.
The following changes since commit 8a7a3d1d0dcf2bb63dafe7275020420005e13e54:
Merge tag 'amd-drm-fixes-5.8-2020-06-17' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-06-19 10:02:30
+1000)
are available in the
This RFC is more of a proof of concept then a fully working solution as there
are a few unresolved issues we are hoping to get advise on from people on the
mailing list.
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbolt connection or by emulation through syfs
Use the new TTM interface to invalidate all exsisting BO CPU mappings
form all user proccesses.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/a
Helper function to be used to invalidate all BOs CPU mappings
once device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
include/drm/ttm/ttm_bo_driver.h | 7 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tt
Some of the stuff in amdgpu_device_fini such as HW interrupts
disable and pending fences finilization must be done right away on
pci_remove while most of the stuff which relates to finilizing and releasing
driver data structures can be kept until drm_driver.release hook is called, i.e.
when the las
No point to try recovery if device is gone, just messes up things.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu
Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash because parent
folder was already removed during pci remove.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 13 +++
drivers/
entity->rq becomes null aftre device unplugged so just return early
in that case.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.
On device removal reroute all CPU mappings to dummy page per drm_file
instance or imported GEM object.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 -
1 file changed, 57 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/d
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 22 i
Hi Adam.
On Mon, Jun 15, 2020 at 09:53:45AM -0500, Adam Ford wrote:
> On Mon, Jun 15, 2020 at 9:46 AM Fabio Estevam wrote:
> >
> > On Mon, Jun 15, 2020 at 10:19 AM Adam Ford wrote:
> > >
> > > The LogicPD Type28 display used by several Logic PD products has not
> > > worked since v5.5.
> >
> > M
Hi Matthias
On Fri, Jun 12, 2020 at 09:22:15AM +0200, Matthias Schiffer wrote:
> From: Matthias Schiffer
>
> This adds a few panels TQ-Systems uses with various starterkit
> mainboards. Device trees actually using these panels will be added with
> a later submission.
>
>
> Matthias Schiffer (2
60 matches
Mail list logo
