Hi,
This series adds the DT bindings and a driver for DisplayPort connector.
I have previously sent v1 and v2 with only the bindings. The bindings
are unchanged, but I updated the patch description slightly for eDP and
DP++.
Tomi
Tomi Valkeinen (2):
dt-bindings: dp-connector: add binding
-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/display-connector.c | 46 +-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index 4d278573cdb9..04362feccd75 100644
don't want to guess what
it could look like, and could it be part of the dp-connector binding.
* No DP++. I'm not familiar with DP++. DP++ might need an i2c bus added
to the bindings.
Signed-off-by: Tomi Valkeinen
---
.../display/connector/dp-connector.yaml | 55 +
Hi Nikhil,
On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> This series moves the tidss to using new connectoe model, where the
> SoC driver (tidss) creates the connector and all the bridges are
> attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
>
> Since the bridges do not create the
Adding Boris who added bus format negotiation.
On 06/10/2020 00:31, Nikhil Devshatwar wrote:
> Hi all,
>
> I am trying to convert the upstream tidss drm driver to new
> connector model.
> The connector is getting created by the tidss driver and bridges are
> attached with flag
Hi Dave,
Can you pick this up to drm-next? Fixes the x64 build warnings for the recent
cdns-mhdp-5.10 pull.
Tomi
On 29/09/2020 12:19, Tomi Valkeinen wrote:
> On x64 we get:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
> conversion from 'long
+++-
> drivers/gpu/drm/tilcdc/tilcdc_drv.h | 7 ++---
> 3 files changed, 26 insertions(+), 35 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
t;drm: bridge: Add support for Cadence MHDP8546 DPI/DP
bridge")
Signed-off-by: Tomi Valkeinen
Reported-by: Stephen Rothwell
Reviewed-by: Swapnil Jakhade
Acked-by: Laurent Pinchart
---
v2:
No changes to code, added tags.
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 +++---
1 file
On 25/09/2020 15:00, Laurent Pinchart wrote:
> On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
>> On 24/09/2020 14:48, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> Thank you for the patch.
>>>
>>> On Wed, Sep 23, 2020 at 11:3
On 24/09/2020 14:48, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
>> On x64 we get:
>>
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
>
On 23/09/2020 23:00, Rob Herring wrote:
> On Wed, Sep 23, 2020 at 11:15 AM Tomi Valkeinen wrote:
>>
>> Hi Rob,
>>
>> On 23/09/2020 19:17, Rob Herring wrote:
>>
>>>> * No eDP. There's really no "eDP connector", as it's always a custom
>
On 23/09/2020 11:30, Tomi Valkeinen wrote:
> On x64 we get:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
> conversion from 'long unsigned int' to 'unsigned int' changes value from
> '18446744073709551613' to '4294967293' [-Woverflow]
>
> The reg
Hi Rob,
On 23/09/2020 19:17, Rob Herring wrote:
* No eDP. There's really no "eDP connector", as it's always a custom
made connection between the DP and the DP panel. So possibly there is
no need for edp-connector binding, but even if there is, I don't want
to guess what it could look
but the
legacy gamma-set ioctl does not work.
This patch adds a new helper, drm_atomic_helper_legacy_degamma_set(),
which can be used instead of drm_atomic_helper_legacy_gamma_set() when
the DEGAMMA_LUT is the underlying property that needs to be set.
Signed-off-by: Tomi Valkeinen
---
drivers/gp
property for CRTC using OVL managers CPR
matrix
drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
Tomi Valkeinen (3):
drm: add legacy support for using degamma for gamma
drm/omap: use degamma property for gamma table
drm/omap: rearrange includes in omapdss.h
drivers
om GAMMA_LUT to DEGAMMA_LUT, and uses
drm_atomic_helper_legacy_degamma_set for gamma_set helper. Thus we will
have:
degamma -> ctm -> out
and the legacy ioctl will continue working as before.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 14 +++---
1 file cha
Drop "uapi/" and rearrange alphabetically.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index ab
-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 104 --
drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 +
drivers/gpu/drm/omapdrm/omap_plane.c | 30
3 files changed, 97 insertions(+), 41 deletions(-)
diff --git a/drivers
a
custom property just for that.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
t;drm: bridge: Add support for Cadence MHDP8546 DPI/DP
bridge")
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/brid
Hi Stephen,
On 23/09/2020 06:36, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
> 'cdns_mhdp_fw_activate':
>
On 21/09/2020 14:49, Pekka Paalanen wrote:
> would it not be simplest if KMS UAPI specification defined the abstract
> color pipeline with all the blocks that may be exposed with
> driver-agnostic UAPI, and then just say that if a block is not present,
> it behaves as pass-through, a no-op?
>
>
Hi,
On 21/09/2020 16:10, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
> ---
> drivers/gpu/drm/omapdrm/dss/hdmi_pll.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_pll.c
>
Hi,
On 04/09/2019 23:20, Ilia Mirkin wrote:
>> Implement CTM color management property for OMAP CRTC using DSS
>> overlay manager's Color Phase Rotation matrix. The CPR matrix does not
>> exactly match the CTM property documentation. On DSS the CPR matrix is
>> applied after
Swapnil Jakhade (4):
phy: Add new PHY attribute max_link_rate
phy: cadence-torrent: Set Torrent PHY attributes
drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
drm: bridge: cdns-mhdp8546: Add TI J721E wrapper
Tomi Valkeinen (1):
Merge tag 'phy-attrs
On 18/09/2020 04:18, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Wed, Sep 16, 2020 at 04:10:08PM +0300, Tomi Valkeinen wrote:
>> Add assigned-clocks, assigned-clock-parents and dma-coherent optional
>> properties.
>>
>> Sig
On 17/09/2020 14:22, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote:
>> Add binding for DisplayPort connector. A few notes:
>>
>> * Similar to hdmi-connector, it has hpd-gpios as an optional property,
>> as the HPD could also
it be part of the
dp-connector binding.
* No DP++. I'm not familiar with DP++, but I think it's all handled by
the DP bridge, and does not need any new properties to the dp-connector.
Signed-off-by: Tomi Valkeinen
---
Changes in v2: Add connector type.
.../display/connector/dp-connector.yaml
k it's all handled by
the DP bridge, and does not need any new properties to the dp-connector.
Signed-off-by: Tomi Valkeinen
---
.../display/connector/dp-connector.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display
Tomi Valkeinen (2):
dt-bindings: display: ti,am65x-dss: add missing properties to
dt-schema
dt-bindings: display: ti,j721e-dss: add missing properties to
dt-schema
.../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++
.../devicetree/bindings/display/ti/ti,j721e
Add assigned-clocks, assigned-clock-parents and dma-coherent optional
properties.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/ti/ti,j721e-dss.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings
Add assigned-clocks, assigned-clock-parents and dma-coherent optional
properties.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings
Hi Swapnil, Yuti,
On 14/09/2020 15:48, Swapnil Jakhade wrote:
> From: Yuti Amonkar
>
> Document the bindings used for the Cadence MHDP8546 DPI/DP bridge in
> yaml format.
>
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent
/tilcdc/tilcdc_drv.h | 7 ++--
> 3 files changed, 59 insertions(+), 38 deletions(-)
>
For both patches:
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_
Hi,
On 08/09/2020 10:55, Stefan Agner wrote:
> On 2020-09-07 20:18, Daniel Vetter wrote:
>> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
>>> Hi Stefan,
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
The lcdif IP
Hi,
On 04/09/2020 05:29, Laurent Pinchart wrote:
>> Laurent mentioned that atomic_check should not change state. Note that
>> cdns_mhdp_validate_mode_params also changes state, as it calculates tu_size,
>> vs and line_thresh.
>
> .atomic_check() isn't allowed to change any global state, which
Hi Milind,
On 03/09/2020 09:22, Milind Parab wrote:
> Also, note that CDNS MHDP implements DP_FRAMER_TU_p where bits 5:0 is
> tu_valid_symbols. So max programmable value is 63.
> Register document gives following explanation
> "Number of valid symbols per Transfer Unit (TU). Rounded down to
On 01/09/2020 22:33, Robin Murphy wrote:
> On 2020-08-26 07:32, Marek Szyprowski wrote:
>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
>> returns the number of the created entries in the DMA address space.
>> However the subsequent calls to the
Hi Swapnil,
On 31/08/2020 11:23, Swapnil Jakhade wrote:
> + line_thresh1 = ((vs + 1) << 5) * 8 / bpp;
> + line_thresh2 = (pxlclock << 5) / 1000 / rate * (vs + 1) - (1 << 5);
> + line_thresh = line_thresh1 - line_thresh2 / mhdp->link.num_lanes;
> + line_thresh = (line_thresh >> 5)
On 01/09/2020 10:46, Tomi Valkeinen wrote:
> I think the above suggests that the driver is not properly updating all the
> registers based on the
> new mode and link. I tried adding cdns_mhdp_validate_mode_params() call to
> cdns_mhdp_atomic_enable(), so that tu-size etc will b
Hi Swapnil,
On 31/08/2020 11:23, Swapnil Jakhade wrote:
> +static int cdns_mhdp_validate_mode_params(struct cdns_mhdp_device *mhdp,
> + const struct drm_display_mode *mode,
> + struct drm_bridge_state *bridge_state)
> +{
On 27/08/2020 02:23, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Wed, Aug 26, 2020 at 04:40:17PM +0300, Tomi Valkeinen wrote:
>> The current EDID allocated with drm_get_edid() is freed when the driver
>> gets a new EDID, but it is not freed
From: Gowtham Tammana
drm_gem_fb_prepare_fb() extracts fence and attaches to plane state.
The fence info is needed if implicit fencing is used. Add this as
prepare_fb function pointer to plane helper funcs.
Signed-off-by: Gowtham Tammana
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm
The current EDID allocated with drm_get_edid() is freed when the driver
gets a new EDID, but it is not freed when the driver is removed, causing
a leak.
Free the EDID (if any) on driver remove.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 2 ++
1 file changed, 2
Hi,
On 11/08/2020 05:36, Laurent Pinchart wrote:
>> +{
>> +u32 max_bw, req_bw, bpp;
>> +
>> +bpp = cdns_mhdp_get_bpp(>display_fmt);
>> +req_bw = mode->clock * bpp / 8;
>> +max_bw = lanes * rate;
> mode->clock is in kHz, while rate is expressed in 10kHz unit if I'm not
> mistaken.
Hi Laurent,
On 23/08/2020 19:26, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote:
>> On 04/08/2020 15:13, Tomi Valkeinen wrote:
>
>>> Can you try to pinpoint a bit where the hang happens? Maybe add
>>> DRM/om
Hi,
On 21/08/2020 10:45, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter
> even when it returns an error code. However, users of
> dsi_runtime_get(), a direct wrapper of pm_runtime_get_sync(),
> assume that PM usage counter will not change on error. Thus a
>
_prime_import(struct drm_device *dev,
> struct dma_buf *buffer);
>
> -vm_fault_t omap_gem_fault(struct vm_fault *vmf);
> int omap_gem_roll(struct drm_gem_object *obj, u32 roll);
> void omap_gem_cpu_sync_page(struct drm_gem_object *obj, int pgoff);
> void oma
is not clear why drm_crtc_vblank_on() and drm_crtc_vblank_get() are
called while holding event_lock. I don't see any problem with moving
those calls outside the lock, which is what this patch does.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 3 ++-
1 file changed, 2
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));
>> +
>> +ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_FULL,
>> +
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 = >connector;
>> +struct drm_bridge *bridge = >bridge;
>> +int ret;
>> +
>> +
On 11/08/2020 03:36, Laurent Pinchart wrote:
> I've got a chance to study the J721E datasheet, and it shows the DP
> bridge has 4 inputs, to support MST. Shouldn't this already be reflected
> in the DT bindings ? I think it should be as simple as having 4 input
> ports (port@0 to port@3) and one
patch does.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_dispc.c | 32 +
drivers/gpu/drm/tidss/tidss_dispc.h | 4
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tid
Hi Guido,
On 12/08/2020 11:39, Guido Günther wrote:
> Hi,
> On Thu, Aug 06, 2020 at 01:34:29PM +0200, Swapnil Jakhade wrote:
>> This patch series adds new DRM bridge driver for Cadence MHDP DPI/DP
>> bridge. The Cadence Display Port IP is also referred as MHDP (Mobile High
>> Definition Link,
gt; embedded Firmware (FW) interfaced over APB interface.
>
> Basically, it takes a DPI stream as input and outputs it encoded in DP
> format. Currently, it supports only SST mode.
>
> Co-developed-by: Tomi Valkeinen
> Signed-off-by: Tomi Valkeinen
> Co-developed-by: Jyri S
On 05/08/2020 13:20, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/omapdrm/dss/venc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
/
>
> -- Sebastian
>
> Sebastian Reichel (4):
> dt-bindings: display: panel-dsi-cm: convert to YAML
> ARM: dts: omap: add channel to DSI panels
> ARM: dts: omap4-droid4: add panel compatible
> ARM: dts: omap4-droid4: add panel orientation
For the series:
Reviewe
On 27/06/2020 01:06, Linus Walleij wrote:
> The OMAP DRM driver includes into the two
> hdmi4.c and hdmi5.c files but does not use any symbols from
> these files. Drop the includes.
>
> Cc: Tomi Valkeinen
> Cc: Tony Lindgren
> Cc: Jyri Sarha
> Signed-off-by: Linus W
Hi,
On 17/07/2020 19:28, Tony Lindgren wrote:
> * Tomi Valkeinen [200618 09:53]:
>> Use SET_LATE_SYSTEM_SLEEP_PM_OPS in DSS submodules to force runtime PM
>> suspend and resume.
>>
>> We use suspend late version so that omapdrm's system suspend callback is
>> c
Hi,
On 03/07/2020 22:36, Sam Ravnborg wrote:
Hi Tomi.
On Fri, Jul 03, 2020 at 10:17:29AM +0300, Tomi Valkeinen wrote:
On 30/06/2020 21:26, Adam Ford wrote:
The drm/omap driver was fixed to correct an issue where using a
divider of 32 breaks the DSS despite the TRM stating 32 is a valid
.parent_clk_name= "dpll4_ck",
.dpi_select_source = _dpi_select_source_omap2_omap3,
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 061552
On 18/06/2020 16:16, Tony Lindgren wrote:
* Tomi Valkeinen [200618 09:53]:
Use SET_LATE_SYSTEM_SLEEP_PM_OPS in DSS submodules to force runtime PM
suspend and resume.
We use suspend late version so that omapdrm's system suspend callback is
called first, as that will disable all the display
Use SET_LATE_SYSTEM_SLEEP_PM_OPS in DSS submodules to force runtime PM
suspend and resume.
We use suspend late version so that omapdrm's system suspend callback is
called first, as that will disable all the display outputs after which
it's safe to force DSS into suspend.
Signed-off-by: Tomi
On 16/06/2020 19:56, Grygorii Strashko wrote:
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of ti-sysc,
will do
pm_runtime_force_xxx() calls
On 11/06/2020 17:00, Grygorii Strashko wrote:
On 09/06/2020 18:26, Tomi Valkeinen wrote:
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
On 15/06/2020 17:53, 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.
Maybe you could tell which commit exactly and then put a
On 09/06/2020 20:10, Tony Lindgren wrote:
On beagle-x15 I see these errors after modprobe:
DSS: OMAP DSS rev 6.1
omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops
[omapdss])
omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops
[omapdss])
[drm]
On 09/06/2020 19:10, Tony Lindgren wrote:
* Tomi Valkeinen [200609 15:38]:
On 09/06/2020 18:12, Tony Lindgren wrote:
* Tomi Valkeinen [200609 10:33]:
Use suspend_late and resume_early callbacks in DSS submodules to force
runtime PM suspend and resume.
We use suspend_late callback so
On 09/06/2020 18:12, Tony Lindgren wrote:
* Tomi Valkeinen [200609 10:33]:
Use suspend_late and resume_early callbacks in DSS submodules to force
runtime PM suspend and resume.
We use suspend_late callback so that omapdrm's system suspend callback
is called first, as that will disable all
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
usage_count of 1, and dispc never suspends fully.
Hmm no idea about that. My guess is that there
-by: Tomi Valkeinen
---
Not fully tested, as I haven't been able to get AM4's system suspend to
work. Works with pm_test.
drivers/gpu/drm/omapdrm/dss/dispc.c | 16
drivers/gpu/drm/omapdrm/dss/dsi.c | 16
drivers/gpu/drm/omapdrm/dss/dss.c | 16
Add connector type for newhaven_nhd_43_480272ef_atxl, as
drm_panel_bridge_add() requires connector type to be set.
Signed-off-by: Tomi Valkeinen
Cc: sta...@vger.kernel.org # v5.5+
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel
On 03/06/2020 17:06, Tony Lindgren wrote:
* Tomi Valkeinen [200603 12:34]:
Hi Tony,
On 31/05/2020 22:39, Tony Lindgren wrote:
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved
The connector type for DISPC's DPI videoport was set the LVDS instead of
DPI. This causes any DPI panel setup to fail with tidss, making all DPI
panels unusable.
Fix this by using correct connector type.
Signed-off-by: Tomi Valkeinen
Fixes: 32a1795f57eecc39749017 ("drm/tidss: New driver f
Hi Tony,
On 31/05/2020 22:39, Tony Lindgren wrote:
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved as we have no suspend and resume functions defined.
Let's fix the issue by
Hi Santosh,
On 14/02/2020 19:40, santosh.shilim...@oracle.com wrote:
On 2/14/20 1:22 AM, Jyri Sarha wrote:
Resend because the earlier recipient list was wrong.
Now that drm/tidss is queued for mainline, lets add display support for
k2g-evm. There is no hurry since tidss is out only in v5.7,
On 06/05/2020 22:02, Sam Ravnborg wrote:
On Wed, Apr 29, 2020 at 01:42:32PM +0300, Tomi Valkeinen wrote:
If videomode_from_timings() returns true, the mode allocated with
drm_mode_create will be leaked.
Also, the return value of drm_mode_create() is never checked, and thus
could cause NULL
Hi Stephen,
On 23/04/2020 06:17, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen
> wrote:
>>
>> On 21/04/2020 04:52, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the drm-misc tree got a conflict
On 14/05/2020 22:09, Sam Ravnborg wrote:
Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.
Signed-off-by: Sam Ravnborg
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c
On 14/05/2020 22:09, Sam Ravnborg wrote:
Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.
Signed-off-by: Sam Ravnborg
Cc: Tomi Valkeinen
Cc: Zheng Bin
Cc: Kate Stewart
Cc: Enrico Weigelt
Cc
On 06/05/2020 11:28, Ricardo Cañuelo wrote:
Hi Tomi,
On mié 06-05-2020 11:01:07, Tomi Valkeinen wrote:
Doesn't all this just point to a bug or missing feature in dt_binding_check?
That's not a reason to change the ABI.
I agree and I'd vote for "missing feature", but seeing that th
Hi Ricardo,
On 06/05/2020 10:21, Ricardo Cañuelo wrote:
Hi Tomi, thanks for reviewing the patch.
On mar 28-04-2020 12:49:28, Tomi Valkeinen wrote:
I don't quite understand this. We cannot have negative numbers in dts files?
Or we can, but dt_binding_check doesn't handle them correctly
On 04/05/2020 13:51, Jyri Sarha wrote:
On 29/04/2020 15:10, Tomi Valkeinen wrote:
AM65x PG1 has a HW issue with YUV pixel formats, resulting in wrong
colors on the screen. This issue is fixed in PG2 hardware.
The driver currently has code to hide YUV pixel formats from the
userspace
, as the
same applications will now work on PG1 and PG2, even if the colors are
wrong on PG1.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_dispc.c | 11 ++-
drivers/gpu/drm/tidss/tidss_dispc.h | 5 -
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers
tilcdc_plane_atomic_check() exits if state->fb == NULL, so no need to
check it again later.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
b/drivers/gpu/
struct platform_driver panel_driver is only used from tilcdc_panel.c, so
it can be static.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc
If videomode_from_timings() returns true, the mode allocated with
drm_mode_create will be leaked.
Also, the return value of drm_mode_create() is never checked, and thus
could cause NULL deref.
Fix these two issues.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6
On 29/04/2020 11:02, Arnd Bergmann wrote:
On Wed, Apr 29, 2020 at 9:56 AM Tomi Valkeinen wrote:
diff --git a/drivers/gpu/drm/bridge/tc358768.c
b/drivers/gpu/drm/bridge/tc358768.c
index 1b39e8d37834..6650fe4cfc20 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge
On 29/04/2020 00:53, Arnd Bergmann wrote:
Some older versions of gcc badly optimize code that passes
an inline function argument into another function by reference,
causing huge stack usage:
drivers/gpu/drm/bridge/tc358768.c: In function 'tc358768_bridge_pre_enable':
On 28/04/2020 12:20, Ricardo Cañuelo wrote:
2) The definition of ti,deskew in the original binding seems to be
tailored to the current driver and the way it's defined may not be very
DT-friendly.
This parameter maps to a 3-bit field in a hardware register that takes
a value from 0 to 7,
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4
.
Fix these two issues.
Signed-off-by: Tomi Valkeinen
---
drivers/video/backlight/led_bl.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 63693c4f0883..699424b111ec 100644
--- a/drivers
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
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video
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 a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d4e1ce684366
wanted. So lets
drop this for now.
- "backlight: led_bl: fix led -> backlight brightness mapping" will now
use max brightness if LED's brightness is higher than highest
backlight brightness level.
- Added reviewed-bys.
Tomi
Tomi Valkeinen (4):
backlight: led_bl: fix cosme
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 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video
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
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video
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 a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d4e1ce684366
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 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video
ess if LED's brightness is higher than highest
backlight brightness level.
- Added reviewed-bys.
Tomi
Tomi Valkeinen (4):
backlight: led_bl: fix cosmetic issues
backlight: led_bl: drop useless NULL initialization
backlight: led_bl: add led_access locking
backlight: led_bl: fix led
1001 - 1100 of 3393 matches
Mail list logo
