-off-by: Darren Etheridge
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
for v1:
- reword comment
Cc: David Airlie
Cc: Darren Etheridge
Cc: Rob Clark
Cc: Russell King
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
---
drivers/gpu/drm/i2c
From: Darren Etheridge
Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: Darre
rd_info.
If it is there, do not try to i2c_new_device as it has already been
registered by DT i2c auto-probing.
Sebastian
c struct drm_i2c_encoder_driver tda998x_driver = {
> + .i2c_driver = {
> + .probe = tda998x_probe,
> + .remove = tda998x_remove,
> + .driver = {
> + .name = "tda998x",
> + },
> + .id_table = tda998x_ids,
> + },
> + .encoder_init = tda998x_encoder_init,
> +};
> +
> +/* Module initialization */
> +
> +static int __init
> +tda998x_init(void)
> +{
> + DBG("");
> + return drm_i2c_encoder_register(THIS_MODULE,&tda998x_driver);
> +}
> +
> +static void __exit
> +tda998x_exit(void)
> +{
> + DBG("");
> + drm_i2c_encoder_unregister(&tda998x_driver);
> +}
> +
> +MODULE_AUTHOR("Rob Clark +MODULE_DESCRIPTION("NXP Semiconductors TDA998X HDMI Encoder");
> +MODULE_LICENSE("GPL");
Maybe stick to one version of "TDA998X" or "TDA998x" ?
Regards,
Sebastian
ess the binding should represent that now already.
I will be a DT stub anyway, the corresponding video sink driver will
have to look it up.
Looking through the bindings for DVI and HDMI, I guess HPD gpio is
better kept in those nodes. From the relevant (DT) properties DVI and
HDMI connectors are in no way different.
Sebastian
On 02/28/14 14:14, Tomi Valkeinen wrote:
> On 28/02/14 14:57, Sebastian Hesselbarth wrote:
>
>> Out of curiosity, will there be DT nodes for pull-up resistors soon,
>> too? ;)
>
> If they don't work automatically, yes, we need DT nodes and drivers for
> them.
>
the compatible string is the easiest way for differentation, at
> least for the three main types, i.e. "dvi-d-connector" etc.
>
> "dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link?
> That looks a bit funny.
maybe like this:
Required Pr
On 02/28/14 14:47, Philipp Zabel wrote:
> Am Freitag, den 28.02.2014, 13:57 +0100 schrieb Sebastian Hesselbarth:
>> On 02/28/14 13:20, Tomi Valkeinen wrote:
>>> This series is a re-send of
>>> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>>>
nstead, or just test against zero for
> no IRQ. It would also be nice to offer this facility to non-DT platforms
> via client->irq. Not every arch in the Linux kernel uses DT.
At least for the DT part, I'd suggest to not ask for interrupt directly
but use a proper gpios property. The can of course be converted to
priv->int_irq in some tda998x_dt_probe.
Sebastian
On 01/12/2014 07:51 PM, Jean-Francois Moine wrote:
> On Sat, 11 Jan 2014 19:35:21 +0100
> Sebastian Hesselbarth wrote:
>
>> At least for the DT part, I'd suggest to not ask for interrupt directly
>> but use a proper gpios property. The can of course be converted t
hat passing
interrupts is fine, too.
We usually have both interrupt-controller; and gpio-controller; set on
DT gpio controllers, so let's stick with irq.
And: Thanks for reviewing this again, I am still too busy to keep up
with it.
Sebastian
can use it for the other variant
specific clocks, too.
FWIW, I totally agree the it was the right thing to wait for you
to sort out the dependencies. Good work, great patience.
Sebastian
On 07/05/2014 02:21 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 05, 2014 at 01:58:37PM +0200, Sebastian Hesselbarth wrote:
>> On 07/05/2014 12:38 PM, Russell King wrote:
>>> Move the variant initialisation entirely to the CRTC init function -
>>> the variant suppo
On 07/11/2014 04:37 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 05, 2014 at 01:58:37PM +0200, Sebastian Hesselbarth wrote:
>> On 07/05/2014 12:38 PM, Russell King wrote:
>>> Move the variant initialisation entirely to the CRTC init function -
>>> the variant suppo
xternal clock available. This is actually something more general
with common clock as it does not handle dynamic clocks yet.
> - display controller
>
>I implemented output port cloning (LCD 0 to port B) but it is not
>tested (I just have a Cubox and I think that Sebastian did no
This adds a video card node required for rmk's dove_drm driver. Reg
property matches reserved memory region (currently 16M at top of memory),
clocks property should carry extclk0 for now.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-kernel at lists.infradead.o
This adds device tree nodes for the lcd controllers found on Marvell
Dove SoCs. For now, there is no DT documentation and clocks property
should refer to clock connected to extclk0 pin.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri
This RFC adds DT support to the DRM driver for Marvell Dove SoCs
posted by Russell King recently. For those booting DT with appended
ATAGs, remember to reduce probed memory by passing mem=1008M as
kernel parameter.
There was an include missing in Russell's RFC that is also added.
Seba
This adds OF support for the Dove DRM driver recently posted as RFC by
Russell King.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: Jason Cooper
Cc: Jean-Francois Moine
---
drivers/gpu/drm/dove
The RFC sent by Russell King was missing an include for tda998x. This
is just a compatible clone to remember Russell to add that later.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: Jason Cooper
On 05/18/2013 07:45 PM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 19:12:18 +0200
> Sebastian Hesselbarth wrote:
>> This adds OF support for the Dove DRM driver recently posted as RFC by
>> Russell King.
>>
...
Jean-Francois,
one thing first: It is an RFC! It i
On 05/18/2013 07:46 PM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 19:12:19 +0200
> Sebastian Hesselbarth wrote:
>
>> The RFC sent by Russell King was missing an include for tda998x. This
>> is just a compatible clone to remember Russell to add that later.
>>
On 05/18/2013 07:33 PM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 19:12:17 +0200
> Sebastian Hesselbarth wrote:
>> This adds a video card node required for rmk's dove_drm driver. Reg
>> property matches reserved memory region (currently 16M at top of memory),
&g
iving
an external encoder (_not_ only tda998x), what gpio pin is connected to
TDA interrupt line, one or two lcds, ...
The corresponding drivers _will_ take care of it .. but in the future.
All I try to make sure is that driver architecture does not prevent us
from e.g. having two lcds plus dcon later on. Or allows to reuse
dove-drm on pxa where only one lcd but no dcon is available.
Sebastian
On 05/18/2013 10:26 PM, Russell King - ARM Linux wrote:
> On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
>> The device for tda998x yes, but not the driver. Anyway, Russel decided
>> to have tda998x probed by his drm_driver.
>
> For the simple reason t
On 05/19/2013 08:01 AM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 21:30:09 +0200
> Sebastian Hesselbarth wrote:
>> So in the end, we will have a DT node for the HW controllers found
>> in Dove SoCs, a node for TDA998x, and a node for the video card, i.e.
>> _how_ l
handling is done threaded with a
workqueue to notify drm backend of HPD events.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Russell King
Cc: Rob Clark
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
This patch currently is based
On 05/19/2013 10:45 PM, Russell King - ARM Linux wrote:
> On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
>> This adds an irq handler for HPD to the tda998x slave encoder driver
>> to trigger HPD change instead of polling. The gpio connected to int
>&
with nodes for the
> individual HW components within it.
I think it would be useful to have the acronyms written out one time
in the document (VC4, HVS).
-- Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signatu
pen.
Would you say there are good solid arguments to shake our current stack
(other than for dusting it off)?
By the way, does DRM improves 2D acceleration support over fbdev?
Thanks,
Sebastian
On 01/31/2013 03:23 PM, Rob Clark wrote:
> On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
> wrote:
>> On 01/29/2013 06:23 PM, Rob Clark wrote:
[...]
>>> +
>>> +/* The TDA9988 series of devices use a paged register scheme.. to
>>> simplify
>>&g
because my (personal) impression is the same Russell
has: Depending on who sends patches, they get merged independent
of how broken they are - others are discussed to death.
Sebastian
On 07/01/13 11:42, Daniel Vetter wrote:
> On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote:
>> at least on this point I do share Russell's impression. I've sent
>> bunch of patches improving TDA998x and DRM+DT:
>> - TDA998x irq handling
lied. In this case we
> + * do not change the clock's rate because the clock may be shared with
> + * other elements. */
Just use clk_set_rate and don't try to make any assumptions. If the
clock you get back is way out of requested pixclk either fail or
just take what you get. HD/SD TV modes usually don't work with wrong
pixclk while VESA modes do.
Audio clock over HDMI will be broken and vert refresh will be wrong but
it is nothing you can check here. Otherwise, I think the patch is going
in the right direction.
Maybe, also clk API should be extended someday to allow to get min/max
frequency range. That will allow us to rule out some modes in a
mode_valid callback based on the pixclk rate.
Sebastian
On 07/01/2013 11:55 PM, Rob Clark wrote:
> On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth
> wrote:
>> - TDA998x irq handling - ignored
>> - TDA998x sync fix - ignored
>
> At least the sync fix, looks like I missed it (it probably is a good
> idea to CC me i
On 07/02/13 03:57, Daniel Drake wrote:
> On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
> wrote:
>> I prefer not to try to find the best clock (source) at all. Let the
>> user pass the clock name by e.g. platform_data (or DT) and just try to
>> get the reque
We add them to dove.dtsi but
disable them by default (status = "disabled").
The DRM driver itself should get a video-card node outside of
soc/internal-regs where you can put e.g. video memory hole (or video
mem size if it will be taken from RAM later)
About the unusual case, I guess we should try to get both lcd
controllers into one DRM driver. Then support mirror or screen
extension X already provides. For those applications where you want
X on one lcd and some other totally different video stream - wait
for someone to come up with a request or proposal.
Sebastian
On 07/02/2013 11:04 PM, Daniel Drake wrote:
> On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
> wrote:
>> I am against a super node which contains lcd and dcon/ire nodes. You can
>> enable those devices on a per board basis. We add them to dove.dtsi but
>> disable
ng it. Maybe I am even missing a very important point
for the super node/phandle proposal, if so, please clarify.
Sebastian
ers shall be used together
> or separately should not affect the devicetree. devicetree is about
> hardware description, not configuration.
Have you had a look at gpio-leds? It _is_ actually a configuration of
GPIO to be used as LED triggers. IMHO DT is just fine for describing
even "virtual" hardware you make up out of existing devices. Without it
there is no way for the subsystems to determine the configuration.
Regarding gpio-leds, how should the driver know the single gpio line
out of tens of available lines, if you do not use a virtual gpio led
node to describe it?
Sebastian
to even have the decision for one or two cards at all.
There is no way for auto-probing the users intention...
Sebastian
tions between devices. While, for example,
a SATA bus master could happily do DMA writes to the GPIO registers just
because it is physically connected to it, it makes no sense. OTOH an LED
connected to a gpio pin is not directly connected to the GPIO register
but at least needs to know who to ask for toggling the line.
I know there may be better examples than those above, but describing
a virtual video card with a supernode connecting separate devices is
sane and sound to me. It is done in a lot other driver subsystems just
the same way, DRM or fbdev is no different from that.
Also, maybe my point-of-view is influenced by how it is done on Marvell
SoCs/boards but I somehow consider it as a worst-case (maybe even
common case for SoCs in general).
Sebastian
s = <&lcd0>; }; };
BoardB.dts:
video { card0 { video-devices = <&lcd1>; }; };
BoardC.dts:
video { card0 { video-devices = <&lcd0 &lcd1>; }; };
and in the driver your are prepared for looping over the video-devices
property and parsing the compatible string of the nodes passed.
Sebastian
On 07/03/13 13:32, Russell King wrote:
> On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
>> But honestly, I see no way around it and it is the only way
>> to allow to even have the decision for one or two cards at all.
>> There is no way for auto-probin
On 07/04/13 11:23, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
>> On 07/04/13 10:53, Sascha Hauer wrote:
>>> On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
>>>> On 07/04/13 10:33, Sas
On 07/04/13 09:05, Inki Dae wrote:
>> -Original Message-
>> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
>> Sent: Wednesday, July 03, 2013 8:52 PM
>> To: Inki Dae
>> Cc: 'Russell King'; devicetree-discuss at lists.ozlab
(IIRC). The driver needs to know what to
wait for, and that is given by the DT super-node.
I consider kernels with missing drivers compared to what is given in
the DT as broken setup. You cannot complain about missing SATA if you
leave out SATA driver, or - if you implemented the driver into two
parts - leave out one of the two SATA driver parts.
Sebastian
, to throw a recent argument back at you: so what in this scenario
>> if you have a driver for the fixed-mode device but not the other device?
>>
>> It's exactly the same problem which you were describing to Sebastian
>> just a moment ago with drivers missing from the s
On 07/04/13 10:53, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
>> On 07/04/13 10:33, Sascha Hauer wrote:
>>>
>>> A componentized device never completes and it doesn't have to. A
>>> componentized device can
On 07/04/13 12:09, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 11:44:41AM +0200, Sebastian Hesselbarth wrote:
>> On 07/04/13 11:30, Sascha Hauer wrote:
>>> On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
>>>> On Thu, Jul 04, 2013 at 10:58:17AM +0200
s "slave-mode" property early, everything should be fine.
All other links required, e.g. lcd0 -> hdmi-transmitter, belong to the
respective nodes in both approaches. DCON existence and requirement is
implicitly put in the driver and not required in DT.
Of course, this is independent of how to handle and register sub-drivers
for DRM. But this is subsystem dependent and also not related to DT.
So for the discussion, I can see that there have been some voting for
super-node, some for node-to-node linking. Although I initially proposed
super-nodes, I can also happily live with node-to-node linking alone.
Either someone can give an example where one of the approaches will not
work (i.MX, exynos?), Grant or one of the DRM maintainers has a
preference, or we are stuck at the decision.
Sebastian
On 07/05/13 11:51, Grant Likely wrote:
> On Fri, Jul 5, 2013 at 10:34 AM, Sebastian Hesselbarth
> wrote:
>> So for the discussion, I can see that there have been some voting for
>> super-node, some for node-to-node linking. Although I initially proposed
>> super-nodes,
t; become available. That means that whoever compiles the kernel must
> take care to not forget to build the clock drivers for all the clocks
> referenced in this part of the DT, but perhaps that is a reasonable
> thing to require.
>
> On the other hand, this problem acts in support
le with each other I think it would be more correct
>> to use same compatible property and DT node aliases, similarly as is now
>> done with e.g. I2C busses:
>>
>> aliases {
>> lcd0 = &lcd_0;
>> lcd1 = &lcd_1;
>> };
>>
>> lcd_0: lcd-controller at 82 {
>> compatible = "marvell,dove-lcd";
>
> I'd much prefer marvell,armada-510-lcd rather than using the codenames for
> the devices. Otherwise we're going to run into totally different things
> being used for different devices (eg, armada-xp...)
>
+1 for using marvell,armada-510-lcd. I like the nick-name "dove" but
armada-510 is much easier to find on Marvell's website.
Sebastian
On 07/25/2013 09:32 PM, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge
> wrote:
>> Russell King and Sebastian Hasselbarth had proposed some very good changes
>> for the tda998x HDMI encoder driver. But when those changes were tested
>> on Beag
comprising the following patches?
Russell King:
drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices
drm/i2c: nxp-tda998x: ensure VIP output mux is properly set
drm/i2c: nxp-tda998x: fix npix/nline programming
drm/i2c: nxp-tda998x: prepare for video input configuration
drm/i2c: nxp-tda998x: add v
sive working, that shouldn't be that
hard to implement.
Will clean-up patches next week and rebase on Russell's RFC.
Sebastian
[1]
http://pdf1.alldatasheet.com/datasheet-pdf/view/347888/NXP/TDA9983B.html
ic const struct armada_output_type armada_drm_conn_slave = {
> + .connector_type = DRM_MODE_CONNECTOR_HDMIA,
For a rework of DRM slave encoder API, there should also be some way to
get .connector_type and .encoder_type above from that slave encoder.
IMHO it should be up to the slave encoder to determine connector and
encoder type.
[...]
> diff --git a/drivers/gpu/drm/armada/armada_slave.h
> b/drivers/gpu/drm/armada/armada_slave.h
> new file mode 100644
> index 000..1b86696
> --- /dev/null
> +++ b/drivers/gpu/drm/armada/armada_slave.h
> @@ -0,0 +1,26 @@
> +/*
> + * Copyright (C) 2012 Russell King
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef ARMADA_TDA19988_H
> +#define ARMADA_TDA19988_H
nit: ARMADA_SLAVE_H
> +
> +#include
> +#include
> +
> +struct armada_drm_slave_config {
> + int i2c_adapter_id;
> + uint32_t crtcs;
> + uint8_t polled;
> + bool interlace_allowed;
> + bool doublescan_allowed;
> + struct i2c_board_info info;
> +};
> +
> +int armada_drm_connector_slave_create(struct drm_device *dev,
> + const struct armada_drm_slave_config *);
> +
> +#endif
Thanks again for sharing the driver as RFC! Will test soon and post
promised tda998x sync patches.
Sebastian
instead of registering a new device.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Airlie
Cc: Russell King - ARM Linux
Cc: Darren Etheridge
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
---
drivers/gpu/drm
This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive modes. Sync timings for a bunch of modes
have also been verified with an oscilloscope near-end (TDA998x input)
and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This
On 06/10/2013 11:48 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
>> On 06/09/13 21:29, Russell King wrote:
>>> +static const struct armada_output_type armada_drm_conn_slave = {
>>> + .connector_type
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is
On 06/11/13 09:24, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 11:23:42PM +0200, Sebastian Hesselbarth wrote:
>> Current DRM slave encoder API conflicts with auto-registration of i2c client
>> when using DT probed clients. To allow DRM slave encoders passed by DT, this
>>
On 06/11/2013 05:10 PM, Francisco Jerez wrote:
> Sebastian Hesselbarth writes:
>>> - I think we could also drop the call to ->set_config since presumably an
>>> of-enabled driver grabbed any required info already from the dt.
>> [...]
>>> I think this
This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive and interlaced modes. Sync timings for a
bunch of modes have also been verified with an oscilloscope near-end
(TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
On 06/20/2013 10:06 PM, Russell King - ARM Linux wrote:
> On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
>> +ref_pix = 3 + mode->hsync_start - mode->hdisplay;
>> +de_pix_s = mode->htotal - mode->hdisplay;
>> +de_pix_
erence for the added flexibility?
I suggest not to do any sophisticated approach to determine the "best"
clock. Just set the SCLK source determined by the name of first clock
passed either by DT or platform_data. This gives everybody the
flexibility but keeps implementation overhead small.
Sebastian
On 06/29/2013 08:45 PM, Russell King - ARM Linux wrote:
> On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
>> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>>>wrote:
>>>>
,
Sebastian
Memory Definitions:
secure memory - Memory allocated in the TEE (Trusted Execution
Environment) which is inaccessible in the REE (Rich Execution
Environment, i.e. linux kernel/user space).
secure handle - Integer value which acts as reference to 'secure
memory'. Used in communicati
dev_err().
The recommended way to do this nowadays looks like this:
return dev_err_probe(dev, PTR_ERR(dsi->phy), "Failed to get mipi dphy");
That will not print anything for -EPROBE_DEFER, but capture
the reason and make it available through
/sys/kernel/debug/devices_deferred if th
lly handled by the device core based on
DT information, except for some drivers which have special needs.
> > And other phys may want to support dynamic switching too, like the
> > Rockchip USBDP combo phy.
>
> I guess USBDP is special in that in also does both modes dynamical
> depending on its use (like type-c with option DP altmode)
The USBDP PHY is indeed quite different from the PHYs in your list
above, but for a different reason: All the combined PHYs you listed
above only support one mode at the same time. E.g. you need to
decide between PCIe, SATA and USB3 mode for the Naneng combophy.
For the USBDP PHY the modes are not mutually exclusive. The USB
controller can request the USBDP PHY in USB mode at the same time
as the DP controller requests it in DP mode. Some additional
registers configure how the lanes are being muxed. A typcial setup
would be 2 lanes for USB3 and 2 lanes for DP.
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
Hi,
On Mon, Dec 02, 2024 at 11:28:13AM +0800, Damon Ding wrote:
> Hi,
>
> On 2024/12/2 6:59, Sebastian Reichel wrote:
> > Hi,
> >
> > On Sat, Nov 30, 2024 at 09:25:12PM +0100, Heiko Stübner wrote:
> > > Am Freitag, 29. November 2024, 03:43:57 CET schrieb Dam
plugging in and unplugging an HDMI or DP cable.
I suppose you could fetch the PHY in power_on() and release it in
power_off(). But using phy_set_mode() might indeed be better here.
-- Sebastian
signature.asc
Description: PGP signature
-by: Jessica Zhang
Reviewed-by: Andy Yan
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67200.c | 503 ++
3 files changed, 514
The Rockchip W552793DBA-V10 display/touchscreen board contains a
Wanchanglong W552793BAA panel, which in turn is using a Raydium
RM67200 MIPI-DSI controller. Add a DT binding for the DSI panel.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel
---
.../bindings/display/panel
having a look.
Greetings,
-- Sebastian
---
Sebastian Reichel (2):
dt-bindings: display: panel: Add Raydium RM67200
drm/panel: add Raydium RM67200 panel driver
.../bindings/display/panel/raydium,rm67200.yaml| 72 +++
drivers/gpu/drm/panel/Kconfig | 10
From: Sebastian Reichel
The Lenovo Thinkpad T14s Gen6 Snapdragon is currently sold with three
different panel versions: OLED, Low Power IPS or IPS with Touchscreen.
My Low Power IPS version had this panel and the kernel complained
about not knowing any details. I don't have any
to the W552793BAA. I put the regulators into the panel
specific section, because the datasheet for the RM67200 specifies
slightly different ones than the w552793baa datasheet. Thus I expect
that other displays might have slight differences.
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
-by: Sebastian Reichel
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67200.c | 503 ++
3 files changed, 512 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel
...@sntech.de/
Thanks for having a look.
Greetings,
-- Sebastian
Sebastian Reichel (2):
dt-bindings: display: panel: Add Raydium RM67200
drm/panel: add Raydium RM67200 panel driver
.../display/panel/raydium,rm67200.yaml| 72 +++
drivers/gpu/drm/panel/Kconfig | 8
The Rockchip W552793DBA-V10 display/touchscreen board contains a
Wanchanglong W552793BAA panel, which in turn is using a Raydium
RM67200 MIPI-DSI controller. Add a DT binding for the DSI panel.
Signed-off-by: Sebastian Reichel
---
.../display/panel/raydium,rm67200.yaml| 72
ndy Yan
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
> drivers/gpu/drm/rockchip/cdn-dp
too.
>
> Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> Signed-off-by: Heiko Stuebner
> Reviewed-by: Quentin Schulz
> Acked-by: Andy Yan
> ---
Reviewed-by: Sebastian Reichel
Tested-by: Sebastian Reichel
-- Sebastian
> changes in v2:
> - drop
6872a2c ("drm/i915/pxp: Implement PXP irq handler")
> Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management")
>
> Signed-off-by: Zhanjun Dong
>
Reviewed-by: Sebastian Brzezinka
--
Best regards,
Sebastian
goto err_ppgtt_cleanup;
+ if (!ppgtt->vm.allocate_va_range) {
+ i915_vm_put(&ppgtt->vm);
+ return 0;
+ }
--
Best regards,
Sebastian
588_GRF_VO1_CON9, val);
> + cfg = of_device_get_match_data(dev);
> + cfg->ctrl_ops->io_init(hdmi);
I think it would be better to store the ctrl_ops (or io_init)
callback in struct rockchip_hdmi_qp during driver probe and avoid
another lookup of the match_data, which involves string comparisons.
Otherwise:
Reviewed-by: Sebastian Reichel
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
all/Z+pFou7KOQZJ1iy4@vaman/
[1]
https://web.git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/commit/?h=next&id=f08d1c08563846f9be79a4859e912c8795d690fd
Greetings,
-- Sebastian
Hi,
On Tue, Feb 18, 2025 at 03:53:06PM +0100, Heiko Stübner wrote:
> Am Dienstag, 18. Februar 2025, 15:13:07 MEZ schrieb Sebastian Reichel:
> > On Tue, Feb 18, 2025 at 08:17:46PM +0800, Jianfeng Liu wrote:
> > > On Tue, 18 Feb 2025 11:00:57 +0100, Heiko Stübnerwrote:
>
uilt-in and the HDMI PHY is build as a
module.
But I also think it would be better to have the clocks defined in the
SoC level DT. I suppose that means vop2_bind would have to check if
the HDMI controller is enabled and only requests pll_hdmiphy
based on that. Considering there is the OF graph
t;
> Signed-off-by: Arun R Murthy
> Reviewed-by: Chaitanya Kumar Borah
> Tested-by: Naveen Kumar
LGTM
Reviewed-by: Sebastian Brzezinka
--
Best regards,
Sebastian
e used
> FIELD_PREP macro. Add this missing include.
>
> Fixes: 328e6885996c ("drm/rockchip: vop2: Add platform specific callback")
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202503040135.fgoywdlb-...@intel.com/
> Signed-off
.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> Remove it.
>
> [...]
Applied, thanks!
[6/9] power: supply: pcf50633: Remove charger
commit: aae075a93f7705e29c599d101abc7e467125d871
Best regards,
--
Sebastian Reichel
is not yet supported upstream and there is no pending patchset. As far
as I know Rockchip plans to work on preparing upstream support for that
soon.
Note, that the two DisplayPort controllers are completely different.
The HDMI/eDP controller is a design from Analogix and the TypeC/DP
controller is a design from Synopsys.
P.S.: Heiko merged support for HDMI1 (RK3588 SoC level) recently. So you
should be able to get that running by some DT additions to the Rock 5
ITX board DT with the latest linux-next code :)
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
s relevant, but while HDMI0 got enabled for quite a
> few devices in 6.13, it did NOT get enabled for Rock 5 ITX.
> I made a local patch (which does the same thing as was done for Rock 5B)
> but I have no idea if it actually works (I don't have the board).
I don't have the board either, but the schematics suggests that your
patch is not correct. On the Rock 5 ITX the RK3588's first HDMI/eDP
port should be enabled in eDP mode to be used with an eDP panel via
connector J11. This series is needed for that.
Greetings,
-- Sebastian
signature.asc
Description: PGP signature
Hi,
On Fri, Feb 07, 2025 at 05:21:46PM +0100, Sebastian Reichel wrote:
> This has been tested in combination with the series from Heiko Stübner
> enabling DSI support for the RK3588 [0] (DSI controller support has been
> merged already, only the PHY support is missing) on the RK3588 EVB1
> - intel_pxp_fini(dev_priv);
> -
> for_each_gt(gt, dev_priv, i)
> intel_gt_driver_unregister(gt);
>
> i915_hwmon_unregister(dev_priv);
>
> i915_perf_unregister(dev_priv);
> - i915_pmu_unregister(dev_priv);
>
> i915_teardown_sysfs(dev_priv);
> +
> +not_registered:
> + intel_pxp_fini(dev_priv);
> + i915_pmu_unregister(dev_priv);
> +
> drm_dev_unplug(&dev_priv->drm);
>
> i915_gem_driver_unregister(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ffc346379cc2c..27a23b1eb9de0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -347,6 +347,8 @@ struct drm_i915_private {
> /* The TTM device structure. */
> struct ttm_device bdev;
>
> + bool registered;
Isn't `struct·drm_device` already has a registered field that could
be used, instead of introducing new variable. It's set in
`int·drm_dev_register(struct·drm_device·*dev,·unsigned·long·flags)`
--
Best regards,
Sebastian
ably should at least get
a MAINTAINERS entry to have you CC'd considering all the PWM bits in
it). See the following discussion (I point you to my message in the
middle of a thread, which has a summary and probably is a good
starting point):
https://lore.kernel.org/all/vc7irlp7nuy5yvkxwb5m7wy7
-by: Jessica Zhang
Reviewed-by: Andy Yan
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67200.c | 499 ++
3 files changed, 510
.
Greetings,
-- Sebastian
---
Sebastian Reichel (2):
dt-bindings: display: panel: Add Raydium RM67200
drm/panel: add Raydium RM67200 panel driver
.../bindings/display/panel/raydium,rm67200.yaml| 72 +++
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel
901 - 1000 of 1165 matches
Mail list logo
