On 08/04/2021 11:13, Chunfeng Yun wrote:
On Wed, 2021-04-07 at 00:24 +0530, Pratyush Yadav wrote:
On 31/03/21 05:24PM, Chunfeng Yun wrote:
On Tue, 2021-03-30 at 23:03 +0530, Pratyush Yadav wrote:
Some platforms like TI's J721E can have the CSI2RX paired with an
external DPHY. Add support to en
Hi,
On 30/03/2021 20:33, Pratyush Yadav wrote:
TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
capture over a CSI-2 bus.
The Cadence CSI2RX IP acts as a bridge between the TI specific parts and
the CSI-2 protocol parts. TI then has a wrapper on top of this bridge
called th
On 25/03/2021 15:05, Laurent Pinchart wrote:
Hi Wan,
Thank you for the patch.
On Thu, Mar 25, 2021 at 07:10:24PM +0800, Wan Jiabing wrote:
struct dss_device has been declared. Remove the duplicate.
And sort these forward declarations alphabetically.
Signed-off-by: Wan Jiabing
Reviewed-by:
On 23/03/2021 13:15, Sebastian Reichel wrote:
Hi,
On Tue, Mar 23, 2021 at 05:34:53PM +0800, Yang Li wrote:
fixed the following coccicheck:
./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
Reported-by: Abaci Robot
Signed-
On 22/03/2021 18:41, Arnd Bergmann wrote:
From: Arnd Bergmann
An old patch added a 'return' statement after each BUG() in this driver,
which was necessary at the time, but has become redundant after the BUG()
definition was updated to handle this properly.
gcc-11 now warns about one such insta
fixes
a warning message.
Thanks you,
I think this looks good now.
Reviewed-by: Jyri Sarha
For the series.
I'll wait a day or two if Tomi has something more to say and merge this
to drm-misc-next.
I had one comment about the print, but otherwise:
Reviewed-by: Tomi Valkeinen
Tomi
On 21/03/2021 10:31, Dario Binacchi wrote:
The warning message did not printed the LCD pixel clock rate but the LCD
clock divisor input rate. As a consequence, the required and real pixel
clock rates are now passed to the tilcdc_pclk_diff().
Signed-off-by: Dario Binacchi
---
Changes in v2:
-
On 18/03/2021 03:02, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/omapdrm/dss/dsi.c
between commit:
690911544275 ("drm/omap: dsi: fix unsigned expression compared with zero")
from the drm-misc-fixes tree and commit:
bbd
Hi,
On 17/03/2021 11:48, ChunyouTang wrote:
From: tangchunyou
1.the type of mipi_dsi_create_packet id int
2.u32 can not < 0
Signed-off-by: tangchunyou
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.
On 14/03/2021 17:13, Dario Binacchi wrote:
As reported by TI spruh73x RM, the LCD pixel clock (LCD_PCLK) frequency
is obtained by dividing LCD_CLK, the LCD controller reference clock,
for CLKDIV:
LCD_PCLK = LCD_CLK / CLKDIV
where CLKDIV must be greater than 1.
Therefore LCD_CLK must be set to
On 14/03/2021 04:15, Laurent Pinchart wrote:
Hi Junlin,
Thank you for the patch.
On Fri, Mar 12, 2021 at 03:14:45PM +0800, angkery wrote:
From: Junlin Yang
r is "u32" always >= 0,mipi_dsi_create_packet may return little than zero.
so r < 0 condition is never accessible.
Fixes coccicheck war
ot blow up LCDC totally?
The fix looks correct to me, but it will change the register value for
boards that have apparently been working for years.
Dario, did you test this on actual HW, or did you just spot the error?
Reviewed-by: Tomi Valkeinen
Tomi
Hi Marc,
On 03/09/2020 19:02, Marc Zyngier wrote:
> The name allocated for the regmap_config structure is freed
> pretty early, right after the registration of the MMIO region.
>
> Unfortunately, that doesn't follow the life cycle that debugfs
> expects, as it can access the name field long after
Adding Jyri with the non-TI address.
Tomi
On 14/02/2021 15:16, Dario Binacchi wrote:
> The fdd property of the tilcdc_panel_info structure must set the reqdly
> bit field (bit 12 to 19) of the raster control register. The previous
> statement set the least significant bit instead.
>
> Signed-o
Dropped the @ti.com addresses and added the new ones.
Tomi
On 29/01/2021 07:58, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang
>
> When run xrandr to change resolution on Beaglebone Black board, it will
> print the error information:
>
> root@beaglebone:~# xrandr -display :0 --outpu
On 27/01/2021 03:51, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> The 'r' in dsi_vc_send_short() is of type 'unsigned int', so the
> 'r < 0' can't be true.
>
> Fix this by introducing a 'err' of type 'int' insteaded.
>
> Fixes: 1ed6253856cb ("drm/omap: dsi: switch dsi_vc_send_long/
Hi,
On 12/01/2021 14:02, Sebastian Reichel wrote:
> [replace Tomi's TI mail address with something working]
>
> Hi,
>
> On Fri, Jan 08, 2021 at 08:58:39PM +0100, Sam Ravnborg wrote:
>> Hi Sebastian,
>>
>> On Fri, Jan 08, 2021 at 12:24:41PM +0100, Sebastian Reichel wrote:
>>> Standard DRM panel d
Update the maintainer email addresses for TI display drivers.
Signed-off-by: Tomi Valkeinen
---
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 281de213ef47..c21471497a18 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
On 14/12/2020 15:46, Zheng Yongjun wrote:
The parameter of kfree function is NULL, so kfree code is useless, delete it.
Signed-off-by: Zheng Yongjun
---
drivers/gpu/drm/omapdrm/tcm-sita.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/tcm-sita.c
b/drivers/gpu/drm
On 09/12/2020 14:08, Daniel Vetter wrote:
> On Wed, Dec 9, 2020 at 1:06 PM Tomi Valkeinen wrote:
>>
>> On 09/12/2020 13:56, Daniel Vetter wrote:
>>> On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen
>>> wrote:
>>>>
>>>> On 09/12/2020 02:48,
On 09/12/2020 13:56, Daniel Vetter wrote:
> On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen wrote:
>>
>> On 09/12/2020 02:48, Daniel Vetter wrote:
>>> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
>>>> Use devm_drm_irq_install to register interrup
On 09/12/2020 02:48, Daniel Vetter wrote:
> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
>> Use devm_drm_irq_install to register interrupts so that
>> drm_irq_uninstall is not needed to be called.
>>
>> Signed-off-by: Tian Tao
>
> There's another drm_irq_install in the error path. Bu
On 27/11/2020 17:37, Ivaylo Dimitrov wrote:
> With 5.9.11 and the patch on top, n900 boots fine, albeit display remains
> blank, could be related to
> brightness, we're still investigating.
Ok. A DSS regdump for a working version and the latest one would be good too.
There's a omapdss
debugfs d
On 27/11/2020 01:17, Ivaylo Dimitrov wrote:
> Hi Tomi,
>
> On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:
>> Hi Aaro, Ivaylo,
>>
>> On 24/11/2020 23:03, Ivaylo Dimitrov wrote:
>>
>>> Is there any progress on the issue? I tried 5.9.1 and still noth
On 25/11/2020 11:07, Daniel Vetter wrote:
>> Laurent, does this ring any bells? The WARN comes in
>> drm_atomic_bridge_chain_enable() when
>> drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge.
>>
>> I'm not sure why the bridge state would not be there.
>
> Lack of state
kka/Domicile: Helsinki
>From 97c55032ac5c44885b0ec219467699af0b6153c1 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen
Date: Thu, 26 Nov 2020 16:04:24 +0200
Subject: [PATCH] drm/omap: sdi: fix bridge enable/disable
When the SDI output was converted to DRM bridge, the atomic versions of
enable and d
On 17/11/2020 15:41, Thomas Zimmermann wrote:
> Hi
>
> Am 17.11.20 um 07:10 schrieb Yang Yingliang:
>> Return -ENOMEM when allocating refill memory failed.
>>
>> Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
>> Reported-by: Hulk Robot
>> Signed-off-by: Yang Yingliang
>>
Hi,
On 21/11/2020 04:02, Saravana Kannan wrote:
> The current implementation of fw_devlink is very inefficient because it
> tries to get away without creating fwnode links in the name of saving
> memory usage. Past attempts to optimize runtime at the cost of memory
> usage were blocked with reques
Hi,
On 13/11/2020 11:46, Yuti Amonkar wrote:
> This patch series add bus format negotiation support for Cadence MHDP8546
> bridge
> driver.
>
> The patch series has four patches in the below sequence:
> 1. drm: bridge: cdns-mhdp8546: Add output bus format negotiation
> Add minimal output bus for
On 22/08/2020 09:57, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter
> even when it returns an error code. However, users of its
> direct wrappers in omapdrm assume that PM usage counter will
> not change on error. Thus a pairing decrement is needed on
> the error
On 13/07/2020 15:28, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b
gem.c:593: warning: Excess function parameter
> 'drm_file' description in 'omap_gem_dumb_create'
> drivers/gpu/drm/omapdrm/omap_gem.c:619: warning: Function parameter or
> member 'offset' not described in 'omap_gem_dumb_map_offset'
>
> Cc: Tomi Valk
On 05/11/2020 20:07, Lee Jones wrote:
> On Thu, 05 Nov 2020, Tomi Valkeinen wrote:
>
>> On 05/11/2020 16:45, Lee Jones wrote:
>>> Fixes the following W=1 kernel build warning(s):
>>>
>>> drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi_print_reset_st
ion in 'omap_irq_disable_vblank'
> drivers/gpu/drm/omapdrm/omap_irq.c:142: warning: Excess function parameter
> 'pipe' description in 'omap_irq_disable_vblank'
>
> Cc: Tomi Valkeinen
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clark
> C
deletions(-)
I'd use "drm/omap: dsi: " subject prefix, the current one is fine too:
Reviewed-by: Tomi Valkeinen
Should I pick this up or do you want to keep the series intact?
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
10 and depends on the
> default state.
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20201027130701.ge5...@atomide.com/
>
> Fixes: 1c4d35265fb2 ("arm64: dts: ti: k3-j721e-main: Add McASP nodes")
> Fixes: 76921f15acc0 ("arm64: dts: ti: k3-j721e-main: Ad
> [1]
> https://lore.kernel.org/linux-arm-kernel/20201027130701.ge5...@atomide.com/
>
> Fixes: 9bcb631e9953 ("arm64: dts: ti: k3-am654-main: Add McASP nodes")
> Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
: 76921f15acc0 ("arm64: dts: ti: k3-j721e-main: Add DSS node")
> Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Signed-off-by: Nishanth Menon
> ---
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 2 +-
>
+ if (tpd->hpd_irq >= 0) {
> ret = devm_request_threaded_irq(&pdev->dev, tpd->hpd_irq, NULL,
> tpd12s015_hpd_isr,
> IRQF_TRIGGER_RISING |
>
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 02/11/2020 11:36, Yuehaibing wrote:
> On 2020/11/2 14:57, Tomi Valkeinen wrote:
>> On 31/10/2020 09:19, Sam Ravnborg wrote:
>>> Hi YueHaibing
>>>
>>> Thanks for the fix. Appreciated but please update as per comments below.
>>>
>>> On S
On 31/10/2020 09:19, Sam Ravnborg wrote:
> Hi YueHaibing
>
> Thanks for the fix. Appreciated but please update as per comments below.
>
> On Sat, Oct 31, 2020 at 11:16:48AM +0800, YueHaibing wrote:
>> gpiod_to_irq() return negative value in case of error,
>> the existing code handle negative erro
On 27/10/2020 05:29, Saravana Kannan wrote:
> Can you try throwing around fw_devlink_pause/resume() around the
> of_platform_populate() call in arch/arm/mach-omap2/pdata-quirks.c?
> Just trying to verify the cause/fix.
AM5 EVM on v5.10-rc1:
[1.139945] cpuidle: using governor menu
[ 13.1264
ixes: afba7e6c5fc1 ("rm: bridge: cdns-mhdp8546: Add TI J721E wrapper")
> Cc: Swapnil Jakhade
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Yuti Amonkar
> Cc: Jyri Sarha
> Signed-off-by: Nishanth Menon
> ---
> drivers/gpu/drm/bridge/cadence/Kconfig | 2 +
v, &led->ldev,
>&init_data);
> if (err < 0) {
> + of_node_put(child);
> if (err != -EPROBE_DEFER)
> dev_err(dev, "couldn't register L
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':
> drivers/gpu/drm/bridge/cad
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
> b/drivers/gpu
Add reset-names as a required property.
There are no dts files using torrent phy yet, so it is safe to add a new
required property.
Signed-off-by: Tomi Valkeinen
---
Changes in v2:
* Base on phy-next
* Update example
* Add torrent_apb
.../devicetree/bindings/phy/phy-cadence-torrent.yaml
, but the current binding requires either no assigned-clocks
or two. Fix this by adding minItems: 1 to all the assigned-clock
properties.
There was also an extra trailing whitespace, which this patch removes.
Signed-off-by: Tomi Valkeinen
---
Changes in v2:
* Base on phy-next
.../devicetree/bin
, but the current binding requires either no assigned-clocks
or two. Fix this by adding minItems: 1 to all the assigned-clock
properties.
There was also an extra trailing whitespace, which this patch removes.
Signed-off-by: Tomi Valkeinen
---
.../devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
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 does
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 m
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 low
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 dma_sync_sg_for_{device,
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 be cal
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)
> +{
Hi,
On 11/08/2020 05:36, Laurent Pinchart wrote:
>> +{
>> +u32 max_bw, req_bw, bpp;
>> +
>> +bpp = cdns_mhdp_get_bpp(&mhdp->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
> mista
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
> pair
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(&mhdp->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 = &mhdp->connector;
>> +struct drm_bridge *bridge = &mhdp->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 o
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, High
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 04/08/2020 15:13, Tomi Valkeinen wrote:
> On 28/07/2020 21:14, Aaro Koskinen wrote:
>> Hi,
>>
>> Looks like N900 display support has broken after v5.6.
>>
>> When using v5.7, or the current mainline (v5.8-rc7), the boot hangs at:
>>
>> [6.2
On 28/07/2020 21:14, Aaro Koskinen wrote:
> Hi,
>
> Looks like N900 display support has broken after v5.6.
>
> When using v5.7, or the current mainline (v5.8-rc7), the boot hangs at:
>
> [6.269500] omapdss_dss 4805.dss: 4805.dss supply vdda_video not
> found, using dummy regulator
>
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
1,
.parent_clk_name= "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
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 at
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&#x
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 Fix
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] Suppor
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 mi
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 as
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 switch
On 28/05/2020 12:14, Ulf Hansson wrote:
On Wed, 27 May 2020 at 10:23, Tomi Valkeinen wrote:
Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core: platform:
Initialize dma_parms for platform devices") in v5.7-rc5 causes
vb2_dma_contig_clear_max_seg_size() to kfree memory th
nctions and move the
dma_set_max_seg_size() calls into the drivers.
Signed-off-by: Tomi Valkeinen
Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform
devices")
Cc: sta...@vger.kernel.org
---
Changes in v2:
* vb2_dma_contig_clear_max_seg_size to empty static
nctions and move the
dma_set_max_seg_size() calls into the drivers.
Signed-off-by: Tomi Valkeinen
---
Note: I have only fully tested this on linux-next, as the capture driver
I use doesn't support unloading modules in v5.7.
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 7 ++---
On 20/05/2020 12:22, Marek Szyprowski wrote:
Hi Tomi,
On 20.05.2020 11:18, Tomi Valkeinen wrote:
On 20/05/2020 12:13, Marek Szyprowski wrote:
On 20.05.2020 11:00, Tomi Valkeinen wrote:
Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core:
platform: Initialize dma_parms for pla
Hi Marek,
On 20/05/2020 12:13, Marek Szyprowski wrote:
Hi Tomi,
On 20.05.2020 11:00, Tomi Valkeinen wrote:
Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core:
platform: Initialize dma_parms for platform devices") v5.7-rc5 causes
at least some v4l2 platform drivers to
Hi,
Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core: platform: Initialize dma_parms for
platform devices") v5.7-rc5 causes at least some v4l2 platform drivers to break when freeing resources.
E.g. drivers/media/platform/ti-vpe/cal.c uses vb2_dma_contig_set_max_seg_size() and
vb2
(Dropping DT from cc)
On 19/05/2020 18:48, Tony Lindgren wrote:
Suspend/resume on am43xx-gpevm is broken right now in mainline and the
regression looks
like it is caused by the display subsystem. I have reported this to Tomi and
its being investigated.
Meanwhile I have tested this patch with
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 conf
On 07/05/2020 20:17, Maxime Ripard wrote:
Actually, for this particular case, consumer driver will be the Cadence MHDP
bridge driver for DisplayPort which is also under review process for
upstreaming [1]. So this DRM bridge driver will make use of the PHY APIs
phy_get_bus_width() and phy_get_max
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':
drivers/gpu/drm/bridge/tc358
fine.
There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.
Signed-off-by: Adam Ford
Cc: Tomi Valkeinen
Cc: sta...@vger.kernel.org
fine.
There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.
Signed-off-by: Adam Ford
Cc: Tomi Valkeinen
Cc: sta...@vger.kernel.org
On 01/10/2019 11:12, Tero Kristo wrote:
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with
the divider clock implementation, I am re-working it as of now.
Basically what is wrong is that with
On 26/09/2019 17:12, Adam Ford wrote:
And what is the hdmi5_configure there? I don't see anything in the
driver that would print hdmi5_configure. And, of course, there's no
hdmi5 on that platform. Hmm, ok... it's from component.c, using "%ps".
Somehow that goes wrong. Which is a bit alarming, bu
On 17/07/2019 17:15, Jean-Jacques Hiblot wrote:
+struct led_classdev *__must_check devm_led_get(struct device *dev,
+ int index)
+{
+ struct led_classdev *led;
+ struct led_classdev **dr;
+
Should you check here if dev->of_node == NULL?
| 79 +---
1 file changed, 20 insertions(+), 59 deletions(-)
For the series:
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 28/05/2019 13:18, Tony Lindgren wrote:
This change lets me boot. I don't know that's the correct place, though:
diff --git a/arch/arm/boot/dts/am5728.dtsi b/arch/arm/boot/dts/am5728.dtsi
index 82e5427ef6a9..c778f9a86b3a 100644
--- a/arch/arm/boot/dts/am5728.dtsi
+++ b/arch/arm/boot/dts/am572
On 22/03/2019 05:28, Andrey Smirnov wrote:
> According to the datasheet tc358767 can transfer up to 16 bytes via
> its AUX channel, so the artificial limit of 8 apperas to be too
> low. However only up to 15-bytes seem to be actually supported and
> trying to use 16-byte transfers results in transf
On 22/03/2019 05:28, Andrey Smirnov wrote:
> A very unfortunate aspect of tc_write()/tc_read() macro helpers is
> that they capture quite a bit of context around them and thus require
> the caller to have magic variables 'ret' and 'tc' as well as label
> 'err'. That makes a number of code paths rat
rchit Taneja
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Cc: Andrey Gusakov
> Cc: Philipp Zabel
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/gpu/drm/bridge
On 15/02/2019 09:12, Andreas Kemnade wrote:
> Hi,
>
> On Fri, 8 Feb 2019 11:13:33 +0200
> Tomi Valkeinen wrote:
>
>> On 05/02/2019 08:38, Andreas Kemnade wrote:
>>> This panel has a backlight, so add a property describing that and
>>> add the code to us
1 - 100 of 895 matches
Mail list logo
