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
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
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
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
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
---
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 ---
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
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 ---
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
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
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 ++
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,
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
> ->
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
>
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
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
> ---
>
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
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 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
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
---
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
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 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
>
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
>>>
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
>
https://bugzilla.kernel.org/show_bug.cgi?id=199475
DCWizard (andrea...@protonmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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
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 =
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
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
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
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
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
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
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
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
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
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 /*
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
---
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
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
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 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
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:
Hi Vinay.
> +
> +static int tc_probe(struct i2c_client *client, const struct i2c_device_id
> *id)
> +{
> + struct device *dev = >dev;
> + struct drm_panel *panel;
> + struct tc_data *tc;
> + int ret;
> +
> + tc = devm_kzalloc(dev, sizeof(*tc), GFP_KERNEL);
> + if (!tc)
>
49 matches
Mail list logo
