uspend happens during PM sleep") for more information.
Fixes: ecfdedd7da5d ("drm/omap: force runtime PM suspend on system suspend")
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion
Hi,
* Tomi Valkeinen [210427 08:47]:
> Hi Tony,
>
> On 26/04/2021 17:12, Tony Lindgren wrote:
> > On resume, dispc pm_runtime_force_resume() is not enabling the hardware
> > as we pass the pm_runtime_need_not_resume() test as the device is suspended
> > with no chi
* Tony Lindgren [210427 10:12]:
> * Tomi Valkeinen [210427 08:47]:
> > If I understand right, this is only an issue when the dss was not enabled
> > before the system suspend? And as the dispc is not enabled at suspend,
> > pm_runtime_force_suspend and pm_runtime_force_r
ier in the
long.
See also earlier commit 88d26136a256 ("PM: Prevent runtime suspend during
system resume") and commit ca8199f13498 ("drm/msm/dpu: ensure device
suspend happens during PM sleep") for more information.
Fixes: ecfdedd7da5d ("drm/omap: force runtime PM suspend
* Tony Lindgren [210427 10:54]:
> * Tony Lindgren [210427 10:12]:
> > * Tomi Valkeinen [210427 08:47]:
> > > If I understand right, this is only an issue when the dss was not enabled
> > > before the system suspend? And as the dispc is not enabled at suspend,
> &g
Hi,
* Laurent Pinchart [210428 14:10]:
> Based on my experience on the camera and display side with devices that
> are made of multiple components, suspend and resume are best handled in
> a controlled way by the top-level driver. Otherwise you end up having
> different components suspending and
* Tomi Valkeinen [210503 08:04]:
> On 29/04/2021 07:46, Tony Lindgren wrote:
> > I think the remaining issue is how dispc should provide services to
> > the other components.
> >
> > If dispc needs to be enabled to provide services to the other modules,
> >
Hi,
* Tony Lindgren [210503 10:45]:
> * Tomi Valkeinen [210503 08:04]:
> > On 29/04/2021 07:46, Tony Lindgren wrote:
> > > Decoupling the system suspend and resume from PM runtime calls for
> > > all the other dss components should still also be done IMO. But
for N950 panel, which is untested.
> >
> > Reported-by: Tony Lindgren
> > Reported-by: Tomi Valkeinen
> > Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core")
> > Signed-off-by: Sebastian Reichel
> > ---
> > I suggest to start by fix the r
Hi,
* Tomi Valkeinen [201124 12:47]:
> From: Sebastian Reichel
>
> In preparation for removing custom DSS calls from the DSI
> panel driver, this moves support for external tearing event
> GPIOs into the DSI host driver. This way tearing events are
> always handled in the core resulting in simp
* Tomi Valkeinen [210211 07:35]:
> On 08/02/2021 19:55, Tony Lindgren wrote:
> > Hi,
> >
> > * Tomi Valkeinen [201124 12:47]:
> >> From: Sebastian Reichel
> >>
> >> In preparation for removing custom DSS calls from the DSI
> >> pa
* Hans Verkuil [210211 12:37]:
> Add cec clock to the dra7 and omap5 device trees.
>
> Signed-off-by: Hans Verkuil
This should merge just fine with what I'm planning to merge for v5.13,
probably best to apply this together with the driver changes:
Acked-by: Tony Lindgren
>
* Tomi Valkeinen [210217 07:42]:
> On 11/02/2021 19:35, Tony Lindgren wrote:
> > * Tomi Valkeinen [210211 07:35]:
> >> On 08/02/2021 19:55, Tony Lindgren wrote:
> >>> Hi,
> >>>
> >>> * Tomi Valkeinen [201124 12:47]:
> >>>&g
* Tomi Valkeinen [210222 08:47]:
> On 18/02/2021 07:57, Tony Lindgren wrote:
> > Oh cool that you have those running again/still :) In this case there
> > is no te-gpios if that might make a difference.
>
> No, GPIO TE is not used on OMAP4 SDP either.
OK
> >>
* Tomi Valkeinen [210226 09:04]:
> Hmm, if I read the code right, TE was not enabled at all before this patch.
> And this patch enables it. So maybe TE has never worked with that panel?
>
> You could try changing the enable_te calls to pass false.
>
> Or with the upstream driver, comment out
>
* Sebastian Reichel [210227 21:51]:
> From: Sebastian Reichel
>
> Disable TE for Droid 4 panel, since implementation is currently
> broken. Also disable it for N950 panel, which is untested.
>
> Reported-by: Tony Lindgren
> Reported-by: Tomi Valkeinen
> Fixes: 4c1b
* Tony Lindgren [210503 11:16]:
> ..the use of pm_runtime_put_sync() like you suggested. I did a quick
> test with the minimal change below and that works :) Seems like that's
> probably the best minimal fix for the -rc cycle.
Sorry I was mistaken, the patch below won't help
* Tony Lindgren [210503 12:18]:
> I think we still fix the dispc related issue too, otherwise the parent
> child_count will just keep increasing on each suspend. I check that
> again though.
After tons more debugging, I found the root cause for the parent child_count
increasing and
all encoders on all boards
> if we want to go that way.
>
> > It would also be nice to convert the DT bindings to YAML :-)
>
> I agree, but not as part of this already 81 patch series. =)
Please feel free to merge this via the dss tree:
Acked-by: Tony Lindgren
_
* Tomi Valkeinen [201124 12:48]:
> From: Sebastian Reichel
>
> The DSI command mode panel is no longer specific
> to OMAP and thus the config option has been renamed
> slightly.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
> Cc: Tony Lindg
* Ivaylo Dimitrov [220105 15:38]:
> Fix that by initializing dma_buf resv to the resv of the gem object being
> exported.
Nice find! This also fixes my wlroots test case with termite running on
sway where termite would only partially update when switching between
desktops, so:
Tested-by
* Tomi Valkeinen [190527 10:51]:
> Hi,
>
> On 23/05/2019 23:07, Sebastian Reichel wrote:
> > Hi,
> >
> > Here is another round of the DSI command mode panel patchset
> > integrating the feedback from PATCHv5. The patches are based
> > on v5.2-rc1 tag. It does not contain the patches required for
Hi,
* Tomi Valkeinen [190528 09:19]:
> On 27/05/2019 14:21, Tony Lindgren wrote:
>
> >> Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I
> >> haven't
> >> been able to test yet. I'll pick the series up in any case, and I
* Tomi Valkeinen [190528 10:05]:
> On 28/05/2019 12:39, Tony Lindgren wrote:
> > Hi,
> >
> > * Tomi Valkeinen [190528 09:19]:
> > > On 27/05/2019 14:21, Tony Lindgren wrote:
> > >
> > > > > Looks good to me. For some reason I can't b
* Tomi Valkeinen [190529 07:06]:
> On 28/05/2019 13:18, Tony Lindgren wrote:
>
> > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel
> > > config.
> >
> > Strange that this is not affecting other x15? I think timer12
* Greg Kroah-Hartman [190122 15:28]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony
flag and making
the current dsi_pll_uninit() into dsi_pll_disable(). This way we can
just call dss_pll_disable() from dsi_display_uninit_dsi() and the
code becomes a bit easier to follow.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 18 --
1 file ch
Hi,
* Tomi Valkeinen [190204 09:57]:
> On 31/01/2019 05:32, Tony Lindgren wrote:
> > Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
> > paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves
>
> But it is paired with dsi_pll_uninit().
* Tomi Valkeinen [190205 11:07]:
> Yep... So there's the DSI internal code which needs to deal with ulps
> and disconnect_lanes, and then the external interface to the DSI PLL (so
> that DPI can use DSI PLL) without ulps/disconnect.
>
> I think your patch breaks this latter one, as disconnect_lan
* Tomi Valkeinen [190206 16:09]:
> On 06/02/2019 18:00, Tony Lindgren wrote:
>
> > OK I'll give it a try. Based on a quick glance, we need to still
> > check for enabled regulator to avoid unpaired calls.
> >
> >> static int dsi_dump_dsi_clocks(struct
* Tomi Valkeinen [190206 09:13]:
> On 05/02/2019 19:58, Tony Lindgren wrote:
> > * Tomi Valkeinen [190205 11:07]:
> >> Yep... So there's the DSI internal code which needs to deal with ulps
> >> and disconnect_lanes, and then the external interface to the DSI PLL (
renumbering of the error path for dsi_display_init_dsi().
Suggested-by: Tomi Valkeinen
Signed-off-by: Tony Lindgren
---
Changes since v1:
- Updated with Tomi's suggested changes to not break DVI with
regulator_enable() made conditional for dsi_display_init_dsi()
- Updated comments to b
* Tomi Valkeinen [190207 09:07]:
> On 06/02/2019 18:29, Tony Lindgren wrote:
>
> > OK. Looks good to me otherwise.
> >
> > So I guess we should fix. Do you want me to post it all
> > as a single patch after some testing?
>
> Yes please =
* Tomi Valkeinen [190208 09:11]:
> Looks fine to me and works on panda. I'll queue this to the next merge
> window (I presume no rush to get this into the current -rcs, it's a bit
> late).
OK good to hear panda works too, my panda is in my rack..
This one has been broken for a long time and nobod
t;
> I guess the question is whether to add alloc_page()/free_page() fallbacks to
> those call sites, or stuff them directly into the CMA helpers here.
Well if you come up with some test patch, I can easily test it :)
> > Would you please test and verify? Thanks!
Yes this revert works
Hi,
Looks like commit d222e42e8816 ("dma-contiguous: do not allocate a
single page from CMA area") caused a regression at least for
omap dss where we now get the following error on init:
omapdss_dispc 58001000.dispc:
dispc_errata_i734_wa_init: dma_alloc_writecombine failed
Any ideas what might b
* Tony Lindgren [190529 08:11]:
> * Tomi Valkeinen [190529 07:06]:
> > On 28/05/2019 13:18, Tony Lindgren wrote:
> >
> > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my
> > > > kernel
> > > > config.
> >
* Tony Lindgren [190530 05:47]:
> * Tony Lindgren [190529 08:11]:
> > * Tomi Valkeinen [190529 07:06]:
> > > On 28/05/2019 13:18, Tony Lindgren wrote:
> > >
> > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my
> > &g
* Hans Verkuil [190325 16:28]:
> On 3/25/19 5:21 PM, Tony Lindgren wrote:
> > * Hans Verkuil [190325 16:12]:
> >> On 3/25/19 4:55 PM, Laurent Pinchart wrote:
> >>>> The reality is that HDMI CEC and HDMI video are really independent of
> >>>> one an
* Hans Verkuil [190325 15:52]:
> Hi Tony,
>
> On 3/25/19 4:32 PM, Tony Lindgren wrote:
> > Hi Hans,
> >
> > Looks like CONFIG_OMAP4_DSS_HDMI_CEC=y blocks SoC core retention
> > idle on omap4 if selected.
> >
> > Should we maybe move hdmi
Suggested-by: Hans Verkuil
Cc: Hans Verkuil
Cc: Jyri Sarha
Cc: Laurent Pinchart
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
b/drivers/g
* Hans Verkuil [190325 16:12]:
> On 3/25/19 4:55 PM, Laurent Pinchart wrote:
> >> The reality is that HDMI CEC and HDMI video are really independent of
> >> one another. So I wonder if it isn't better to explain the downsides
> >> of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC
> >>
Hi Hans,
Looks like CONFIG_OMAP4_DSS_HDMI_CEC=y blocks SoC core retention
idle on omap4 if selected.
Should we maybe move hdmi4_cec_init() to hdmi_display_enable()
and hdmi4_cec_uninit() to hdmi_display_disable()?
Or add some enable/disable calls in addtion to the init and
uninit calls that can
* Hans Verkuil [190326 06:36]:
> On 3/26/19 12:47 AM, Tony Lindgren wrote:
> > @@ -169,12 +169,19 @@ static int hdmi_cec_adap_enable(struct cec_adapter
> > *adap, bool enable)
> > struct hdmi_core_data *core = cec_get_drvdata(adap);
> > int temp, err
Suggested-by: Hans Verkuil
Cc: Hans Verkuil
Cc: Jyri Sarha
Cc: Laurent Pinchart
Signed-off-by: Tony Lindgren
---
Changes since v1:
- Move clock enable to happen after the whole disable section rather than
add a pointless test for enable as noted by Hans
- Move clock enable to happen after hd
ied in the lm3532 tread. So as far as I'm concerned,
we're good to go:
Tested-by: Tony Lindgren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
* Arnd Bergmann [220420 19:18]:
> On Wed, Apr 20, 2022 at 3:46 PM Aaro Koskinen wrote:
> >
> > Hi,
> >
> > On Tue, Apr 19, 2022 at 03:37:08PM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The address range 0xfee0-0xfeff is used for PCI and
> > > PCMCIA I/O port mappin
* Arnd Bergmann [220419 13:36]:
> From: Arnd Bergmann
>
> omap2 stopped using this code with commit 8d39ff3d1696 ("ARM: OMAP2+:
> Remove unused legacy code for timer"), so just move it to mach-omap1 now,
> along with the other half of that driver.
BTW, if omap1 gains devicetree support, chances
* Arnd Bergmann [220419 13:39]:
> From: Janusz Krzysztofik
> + /* protect clk->enable_reg from concurrent access via clk_set_rate() */
> + if (clk->enable_reg == OMAP1_IO_ADDRESS(ARM_CKCTL))
> + spin_lock_irqsave(&arm_ckctl_lock, flags);
> + else if (clk->enable_reg == OMA
just fine for me.
I don't currently have any omap1 hardware online to test with.
For the patches, please feel free to add:
Acked-by: Tony Lindgren
* Arnd Bergmann [220419 13:37]:
> From: Arnd Bergmann
>
> The sram initialization code is the only shared omap1/2 code that
> is not a standalone driver, but it is very short. Having two copies
> of this code means some duplication of the sources, but actually
> saves object code size as it can
* Nishanth Menon [220412 21:18]:
> On 17:24-20220412, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 14/03/2022 13:37, Devarsh Thakkar wrote:
> > > Soft reset the display subsystem controller on startup and wait for
> > > the reset to complete. This helps the scenario where display was
> > > already in
* H. Nikolaus Schaller [191018 18:47]:
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.txt
> @@ -0,0 +1,76 @@
> +Imagination PVR/SGX GPU
> +
> +Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered by
> this binding.
> +
> +Required properties:
> +- co
* H. Nikolaus Schaller [191107 11:07]:
> +- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530",
> "img,sgx5"
This should be without the x, maybe use the earliest one here
for "ti,am3352-sgx530-125" like we have for "ti,am3352-uart".
We could use "ti,am3-sgx530-125" but that c
* H. Nikolaus Schaller [191107 11:07]:
> +- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530",
> "img,sgx5"
I did a quick probe test for the module and am4 is the same
as am335x, so please also add this for the next version:
"ti,am4-sgx530-125"
Regards,
Tony
__
* H. Nikolaus Schaller [191107 16:56]:
> > Am 07.11.2019 um 15:35 schrieb Rob Herring :
> > On Thu, Nov 7, 2019 at 5:06 AM H. Nikolaus Schaller
> > wrote:
> >> Clock, Reset and power management should be handled
> >> by a parent node or elsewhere.
> >
> > That's probably TI specific...
>
> Yes
* Sebastian Reichel [191118 15:03]:
> On Mon, Nov 18, 2019 at 03:37:12PM +0100, H. Nikolaus Schaller wrote:
> > > Am 18.11.2019 um 15:33 schrieb Sebastian Reichel
> > > :
> > > On Mon, Nov 18, 2019 at 03:05:07PM +0200, Tomi Valkeinen wrote:
> > >> On 17/11/2019 04:39, Sebastian Reichel wrote:
> >
* Sebastian Reichel [191117 07:11]:
> We can simply use the atomic helper for
> handling the dirtyfb callback.
...
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> -void omap_crtc_flush(struct drm_crtc *crtc)
> +static void omap_crtc_flush(struct drm_crtc *
* Laurent Pinchart [191202 13:05]:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote:
> > panel-simple now handled panel osd070t1718-19ts, and we no longer need
> > the panel timings in the DT file. So remove them.
>
> Should you in that
* Laurent Pinchart [191202 13:02]:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Thu, Nov 14, 2019 at 11:39:48AM +0200, Tomi Valkeinen wrote:
> > The LCD panel on AM4 GP EVMs and ePOS boards seems to be
> > osd070t1718-19ts. The current dts files say osd057T0559-34ts. Possibly
> > the panel has
Hi,
* Tomi Valkeinen [191125 05:11]:
> Add HDMI support for AM437x GP EVM. The HDMI uses SiI9022 HDMI encoder,
> and is mutually exclusive with the LCD. The choice between LCD and HDMI
> is made by booting either with am437x-gp-evm.dtb or
> am437x-gp-evm-hdmi.dtb.
So Linux kernel needs a new boa
* Peter Ujfalusi [191204 11:26]:
>
>
> On 04/12/2019 12.55, Jyri Sarha wrote:
> > Move to use the new drm panel support in tilcdc together with added
> > "newhaven,nhd-4.3-480272ef-atxl"-panel support in drm panel-simple.
>
> Tested-by: Peter Ujfalusi
Thanks applying into omap-for-v5.6/dt.
T
* Tony Lindgren [191212 17:21]:
> Hi,
>
> * Tomi Valkeinen [191125 05:11]:
> > Add HDMI support for AM437x GP EVM. The HDMI uses SiI9022 HDMI encoder,
> > and is mutually exclusive with the LCD. The choice between LCD and HDMI
> > is made by booting either with am43
* Jyri Sarha [191203 01:12]:
> Move to use the new drm panel support in tilcdc together with added
> "tfc,s9700rtwv43tr-01b"-panel support in drm panel-simple.
>
> Signed-off-by: Jyri Sarha
> Reviewed-by: Laurent Pinchart
> ---
> "tfc,s9700rtwv43tr-01b" in panel-simple has been in for some time
* Tomi Valkeinen [191213 12:34]:
> On 13/12/2019 14:28, Laurent Pinchart wrote:
>
> > > So... In the DT file, we would have multiple endpoints in the same output
> > > port in DSS, one going to
> > > the panel, one to the SiI9022? omapdrm could then create two encoders,
> > > one abstracting th
ichel
Cc: Tomi Valkeinen
Signed-off-by: Tony Lindgren
---
Matthijs, do you have some more info to add to the description?
drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/o
* Tony Lindgren [191220 16:57]:
> Looking around what might affect BO_TILED, I noticed Matthijs had this
> change in his earlier pyra tiler patches. The earlier patch "XXX omapdrm:
> force tiled buffers to be pinned and page-aligned" has no commit log
> though, so I'm
* Matthijs van Duin [200104 05:10]:
> On Sat, Dec 21, 2019 at 08:41:41AM -0800, Tony Lindgren wrote:
> > Also, I'm wondering if this change makes sense alone without the pinning
> > changes for a fix, or if also the pinning changes are needed.
>
> Both pinning and page-
* Matthijs van Duin [200104 04:53]:
> On Fri, Dec 20, 2019 at 04:57:11PM -0800, Tony Lindgren wrote:
> > On my droid4 I noticed bad constant tearing on the LCD with stellarium in
> > landscape mode with xorg-video-omap rotated with xrandr --rotate right.
> > Every sec
* Pavel Machek [200105 18:32]:
> Hi!
>
> It would be good to get LED backlight to work in clean way for 5.6
> kernel.
I agree, this is badly needed for many devices.
> [If you have an idea what else is needed, it would be welcome; it
> works for me in development tree but not in tree I'd like t
Hi,
* Tony Lindgren [200104 05:51]:
>
> Just changing the alingment fixes the issue. Looks like the minimum
> alignment we currently allow is 128, I think 512 was the minimum
> that worked for me, so maybe the right fix would be to just change
> the minimum to 512 with no speci
ey nice catch. Based on a quick test looks like this fixes an
issue where power consumption stays higher after using HDMI.
Would be nice to have merged in the v5.4-rc series:
Tested-by: Tony Lindgren
___
dri-devel mailing list
dri-devel@lists.f
* Tomi Valkeinen [191008 14:17]:
> On 08/10/2019 17:13, Tony Lindgren wrote:
> > * Tomi Valkeinen [190930 10:38]:
> > > If use_mclk is false, mclk_mode is written to a register without
> > > initialization. This doesn't cause any ill effects as the written value
* Tomi Valkeinen [191010 06:48]:
> On 08/10/2019 17:21, Tony Lindgren wrote:
> > * Tomi Valkeinen [191008 14:17]:
> > > On 08/10/2019 17:13, Tony Lindgren wrote:
> > > > * Tomi Valkeinen [190930 10:38]:
> > > > > If use_mclk is fals
* Tomi Valkeinen [191011 10:25]:
> On 10/10/2019 16:24, Tony Lindgren wrote:
>
> > Hmm so what register does this clock actually change?
> >
> > I'm seeing an increase of few tens of extra mW, which means at
> > least one day of standby time less for me :) I
* H. Nikolaus Schaller [191021 15:46]:
> > Am 21.10.2019 um 17:07 schrieb Rob Herring :
> > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> > wrote:
> >> +- reg: Physical base addresses and lengths of the register areas.
> >
> > How many?
>
> I assume there is only one. At least
* H. Nikolaus Schaller [191021 15:46]:
> > Am 21.10.2019 um 17:07 schrieb Rob Herring :
> > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> > wrote:
> >> +Optional properties:
> >> +- timer: the timer to be used by the driver.
> >
> > Needs a better description and vendor prefix at
* Adam Ford [191016 06:53]:
> With the removal of the panel-dpi from the omap drivers, the
> LCD no longer works. This patch points the device tree to
> a newly created panel named "logicpd,type28"
>
> Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
>
> Signed-off-by: Adam Ford
> Ack
* H. Nikolaus Schaller [191021 18:08]:
>
> > Am 21.10.2019 um 19:25 schrieb Tony Lindgren :
> >
> > * H. Nikolaus Schaller [191021 15:46]:
> >>> Am 21.10.2019 um 17:07 schrieb Rob Herring :
> >>> On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schall
* H. Nikolaus Schaller [191022 15:12]:
> Hm. How should that work? Some SoC have the sgx544 as single
> core and others as dual core. This imho does not fit into
> the "img,sgx544-$revision" scheme which could be matched to.
Well don't you have then just two separate child nodes,
one for each cor
* Merlijn Wajer [200211 12:54]:
> Hi,
>
> On 11/02/2020 12:08, Tomi Valkeinen wrote:
> > On 11/02/2020 13:07, Laurent Pinchart wrote:
> >
> >>> Hopefully soon (in five years? =) we can say that omapdrm supports all
> >>> the boards, and we can deprecate omapfb.
> >>
> >> I'd love to send a patch
* Tomi Valkeinen [200211 16:14]:
> On 11/02/2020 18:05, Tony Lindgren wrote:
> > * Merlijn Wajer [200211 12:54]:
> > > Hi,
> > >
> > > On 11/02/2020 12:08, Tomi Valkeinen wrote:
> > > > On 11/02/2020 13:07, Laurent Pinchart wrote:
> > >
ght driver". Everything should
> > be ready for it. I'm sorry if I broke something working, I was not
> > aware it worked at all.
> >
> > Unfortunately, this is backlight code, not LED, so I can't just merge it.
>
> Please go ahead. Apply my Acked-by and merge away ASAP.
>
> Acked-by: Lee Jones
OK best to merge the driver via the LED tree:
Acked-by: Tony Lindgren
Tested-by: Tony Lindgren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > Signed-off-by: Tomi Valkeinen
> > > Signed-off-by: Jean-Jacques Hiblot
> > > Acked-by: Pavel Machek
> > > Reviewed-by: Daniel Thompson
> > > Acked-by: Lee Jones
> > > Acked-by: Tony Lindgren
> > > Tested-by:
> > > > > merge it to fix it rather than start scrambling with other
> > > > > > temporary hacks?
> > > > >
> > > > > We should just merge the "add led-backlight driver". Everything should
> > > > > be ready for it. I'm sorry
; Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jean-Jacques Hiblot
> Acked-by: Pavel Machek
> Reviewed-by: Daniel Thompson
> Acked-by: Lee Jones
> Acked-by: Tony Lindgren
> Tested-by: Tony Lindgren
> Signed-off-by: Pavel Machek
> ---
> drivers/video/backlight/Kconf
* Lee Jones [200220 07:49]:
> On Wed, 19 Feb 2020, Tony Lindgren wrote:
>
> > * Pavel Machek [200219 19:15]:
> > > From: Tomi Valkeinen
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except
* Sebastian Reichel [200219 23:45]:
> Finally :)
>
> Reviewed-by: Sebastian Reichel
Yeah thanks for your persistent effort on getting this working :)
Regards,
Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskto
* Laurent Pinchart [200224 23:38]:
> Hi Sebastian,
>
> Thank you for the patch.
>
> On Tue, Feb 25, 2020 at 12:20:32AM +0100, Sebastian Reichel wrote:
> > Add Droid 4 specific compatible value in addition to the
> > generic one, so that we have the ability to add panel
> > specific quirks in the
Valkeinen
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 131 +-
include/linux/platform_data/ti-sysc.h | 1 +
2 files changed, 129 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sy
ted dts changes separately.
Regards,
Tony
Tony Lindgren (3):
drm/omap: Prepare DSS for probing without legacy platform data
bus: ti-sysc: Detect display subsystem related devices
bus: ti-sysc: Implement display subsystem reset quirk
drivers/bus/ti-sysc.c
* Sebastian Reichel [200224 23:32]:
> Hi,
>
> On Mon, Feb 24, 2020 at 11:12:28AM -0800, Tony Lindgren wrote:
> > In order to probe display subsystem (DSS) components with ti-sysc
> > interconnect target module without legacy platform data and using
> > devicetree, we n
and
omap4 HDMI. The rest is just naming of modules if CONFIG_DEBUG
is set.
Cc: Jyri Sarha
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/
he component code to consider device tree subnodes
Cc: dri-devel@lists.freedesktop.org
Cc: Jyri Sarha
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Signed-off-by: Tony Lindgren
---
This is needed for dropping DSS platform data that I'll be posting
seprately. If this looks OK, can you guys please te
* Sebastian Reichel [200224 23:22]:
> This updates the existing omapdrm DSI code, so that it uses
> common drm_mipi_dsi API and drm_panel.
>
> The patchset has been tested with Droid 4 using Linux console, X.org and
> Weston. The patchset is based on Laurent Pinchartl's patch series [0]
> and rem
* Tony Lindgren [200225 18:38]:
> Only lightly tested so far, please test. Also, I'm not sure if we
> should get the id from somewhere for drm_handle_vblank() instead of
> just using 0?
Also looks like we can now get WARN_ON(omap_crtc->pending)
in omap_crtc_arm_event(), so obvio
* Sebastian Reichel [200225 23:03]:
> Hi,
>
> On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote:
> > * Sebastian Reichel [200225 02:29]:
> > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote:
> > > > BTW, I think there's
* Sebastian Reichel [200225 02:29]:
> On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote:
> > BTW, I think there's also some refcount issue in general where
> > the omapdrm related modules cannot be unloaded any longer?
>
> I wouldn't be too surpri
4x768@60
Fixes: 47103a80f55a ("drm/omap: add framedone interrupt support")
Cc: Ivaylo Dimitrov
Cc: Merlijn Wajer
Cc: Sebastian Reichel
Cc: ruleh
Signed-off-by: Tony Lindgren
---
Only lightly tested so far, please test. Also, I'm not sure if we
should get the id from somewhere for drm_h
* Tony Lindgren [200225 22:35]:
> * Tony Lindgren [200225 19:53]:
> > * Tony Lindgren [200225 18:38]:
> > > Only lightly tested so far, please test. Also, I'm not sure if we
> > > should get the id from somewhere for drm_handle_vblank() instead of
> > >
1 - 100 of 360 matches
Mail list logo
