> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Cong Yang
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Cong Yang
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
d 0x29 cmds invoked at prepare()
> function.
>
> Note:0x11 is mipi_dsi_dcs_exit_sleep_mode
> 0x29 is mipi_dsi_dcs_set_display_on
>
> [1]:
> https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com
>
> Signed-off-by: Cong Yang
With Doug
anels, based on DTS sources in Linux kernel (assume all devices take
> only one channel number).
>
> Signed-off-by: Krzysztof Kozlowski
Looks right to me.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
62365248-988
> Total: Before=10651, After=9663, chg -9.28%
>
> Cc: Ritesh Kumar
> Signed-off-by: Douglas Anderson
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
As for the behaviour of .remove() I doubt whether in many cases
the original driver authors have even tested this themselves.
I would say we should just apply the series as soon as it's non-RFC
after the next merge window and see what happens. I doubt it
will cause much trouble.
The series:
Acked-by: Linus Walleij
Yours,
Linus Walleij
lore.kernel.org/r/20230921192749.1542462-1-diand...@chromium.org
>
> Cc: Laurent Pinchart
> Cc: Sebastian Reichel
> Signed-off-by: Douglas Anderson
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, May 3, 2024 at 11:38 PM Douglas Anderson wrote:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these
ng to disable.
>
> Cc: Laurent Pinchart
> Cc: Sebastian Reichel
> Signed-off-by: Douglas Anderson
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
t hex numbers to
> lower case as per kernel conventions.
>
> Signed-off-by: Douglas Anderson
With the mentioned bugfix:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
gt; nt36672e_1080x2408_60hz_init62365248-988
> Total: Before=10651, After=9663, chg -9.28%
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
can perhaps get others to chime in to see which style they
> prefer? Let me know what you think.
I'm in favor of this design.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
ince we're touching all the tables, let's also convert hex numbers to
> lower case as per kernel conventions.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Linus Walleij
Thanks for doing this Doug, everything is starting to look much
better after this series, and I hope we can keep Chromium display
drivers looking this good going forward.
Yours,
Linus Walleij
lower case as per kernel conventions.
>
> Signed-off-by: Douglas Anderson
Wow that's a *VERY* nice patch.
Reviewed-by: Linus Walleij
The metrics surprisingly reports more compact object code,
I wasn't expecting this, but it's nice.
Yours,
Linus Walleij
ing in the chatty function and a function call at the invoking
site".
With some explanation like that +/- added in:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
17080 10640 -6440
> nt36672e_1080x2408_60hz_init._rs 10320 - -10320
> Total: Before=31815, After=15055, chg -52.68%
>
> Signed-off-by: Douglas Anderson
OK then!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
es match so let's
> fix it.
>
> Fixes: a9015ce59320 ("drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro")
> Signed-off-by: Douglas Anderson
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
match so let's
> fix it.
>
> Fixes: 2a9e9daf7523 ("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro")
> Signed-off-by: Douglas Anderson
All right! Nice work.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
ivo_t109nw41
> together to make a separate driver and break out boe-tv101wum-nl6 ,
> because they belong to the same controller.
Aha OK sorry for my misunderstanding!
We are all in agreement.
Yours,
Linus Walleij
se the power supply is quick to be overloaded by the
> backlight.
Thanks then I bet the prototype 8060 MMCC driver needs similar fixes
before it will work as well, so we should work to merge this, then look at
8060 support after that.
Yours,
Linus Walleij
5",
.data = _frida_frd400b25025,
},
{
.compatible = "hydis,hva40wv1",
.data = _hydis_hva40wv1,
},
{ }
};
Take some inspiration from this driver and how we parameterize
the different data depending on compatible string.
Yours,
Linus Walleij
.
Yours,
Linus Walleij
ipi_dsi_dcs_exit_sleep_mode(), delay, send
command sequence, delay, call mipi_dsi_dcs_set_display_on()
and delay where any delay can be 0.
This achieves the same goal without messing up the whole place,
but requires some tinkering with how to pass a sequence the right
way etc.
Are Google & partners interested in the job? ;)
Yours,
Linus Walleij
On Sun, Mar 31, 2024 at 10:45 AM Krzysztof Kozlowski
wrote:
> virtio core already sets the .owner, so driver does not need to.
>
> Acked-by: Bartosz Golaszewski
> Acked-by: Viresh Kumar
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Linus Walleij
Yours,
Linus Walleij
it got
> in the way, using the syntax that is supported by both compilers.
>
> Fixes: 2cd3271b7a31 ("kbuild: avoid duplicate warning options")
> Signed-off-by: Arnd Bergmann
Neat!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
sztof Kozlowski
(...)
> drivers/pinctrl/tegra/pinctrl-tegra-xusb.c | 2 +-
Acked-by: Linus Walleij
Yours,
Linus Walleij
- BACKLIGHT_KTD2801 [=m] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=m]
>
> Fixes: 66c76c1cd984 ("backlight: Add Kinetic KTD2801 backlight support")
> Signed-off-by: Duje Mihanović
Acked-by: Linus Walleij
Technically you can also select GPIOLIB, because it
$id:
> http://devicetree.org/schemas/display/panel/novatek,nt35510.yaml#
This is because the checker is applying the patch on something that is not
drm-misc-next.
I think the patch is fine.
Yours,
Linus Walleij
abstracting out the library and the library
has the change I requested so:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
xtern" since it is default I think even
checkpatch complains about it these days?
Anyway, no big deal:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
you use usleep_range() instead, at least for this one?
> + for (int i = 0; i < 8; i++) {
> + u8 next_bit = (brightness & 0x80) >> 7;
I would just:
#include
bool next_bit = !!(brightness & BIT(7));
Yours,
Linus Walleij
maxItems: 1
First I thought this was inconsistent with ktd253, then
I looked at the datasheets and they really did change "en" to "ctrl" so
this needs a new name indeed.
With commit message added:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
esh Kumar
Patch applied to drm-misc-next on top of the commit that need fixing.
Yours,
Linus Walleij
On Fri, Dec 22, 2023 at 4:02 AM Samuel Dionne-Riel
wrote:
> Signed-off-by: Samuel Dionne-Riel
The patch looks OK, it was missing a commit message so I added
one and applied the patch to drm-misc-next.
Yours,
Linus Walleij
> So in short this panel is the model 9A-3R063-1102B from DJN, which uses
> a Himax HX83112A driver IC.
So compatible = "djn,9a-3r063-1102b" since the setup sequences for
hx83112a are clearly for this one display?
Yours,
Linus Walleij
s HX8394 to
be using a Truly controller as well, hence the similarities.
In a datasheet for their TFT800480-84-V1-E display controller
Truly kept the init sequence name of void LCD_INIT_HX8290(void)
for example.
Yours,
Linus Walleij
main concern is that the next display using the same IC
need to find the right file to patch.
Yours,
Linus Walleij
On Tue, Jan 9, 2024 at 1:54 PM Dario Binacchi
wrote:
> > do you want me to apply patches 5,7,8 to the dri-misc
(...)
> Yes, I would appreciate that very much.
Pushed to drm-misc-next!
Please submit the DTS files through the ST SoC tree.
Yours,
Linus Walleij
Hi Dario,
do you want me to apply patches 5,7,8 to the dri-misc
tree?
Yours,
Linus Walleij
<0x1000 0 0 4 6>;
This interrupt-map looks very strange, usually the last cell is the polarity
flag and here it is omitted? I would expect something like:
<0x 0 0 1 5 IRQ_TYPE_LEVEL_LOW>, (...)
The interrupt-map schema in dtschema isn't really looking at this
so it is easy to get it wrong.
Yours,
Linus Walleij
ou know from the compatible that this is "renesas,sh7751-intc"
and I bet this table will be the same for any sh7751 right?
Then just put it in a table in the driver instead and skip this from
the device tree and bindings. If more interrupt controllers need
to be supported by the driver, you can simply look up the table from
the compatible string.
Yours,
Linus Walleij
On Wed, Jan 3, 2024 at 2:31 PM Tomi Valkeinen
wrote:
> Two small fixes to sii902x for crashes.
>
> Signed-off-by: Tomi Valkeinen
These look good to me!
Acked-by: Linus Walleij
Yours,
Linus Walleij
the GPIO, so very logical. So I
would certainly remove this .strict setting, but maybe Alexandre
et al have a strong opinion about it.
> Another option to fix my use case without introducing regressions
> could be to add a
> new property to the device tree that suggests whether to call
> devm_gpiod_get_optional()
> with the GPIOD_ASIS or GPIOD_OUT_HIGH parameter.
>
> What is your opinion?
It's fine either way, but just use GPIOD_OUT_HIGH and I can test
it on my system as well, I think it's fine.
Yours,
Linus Walleij
gisters have
> been set to their default values according to the specifications found
> in the datasheet.
>
> [1]
> https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/Components/nt35510/
> Signed-off-by: Dario Binacchi
>
> ---
>
> (no changes si
0_DOPCTR_0_EOTP |
+ NT35510_DOPCTR_0_N565, NT35510_DOPCTR_1_CTB },
+ .madctl = NT35510_ROTATE_180_SETTING,
Changing this to NT35510_ROTATE_0_SETTING makes it work
fine again.
With that change:
Reviewed-by: Linus Walleij
Tested-by: Linus Walleij
Yours,
Linus Walleij
On Thu, Jan 4, 2024 at 9:42 AM Dario Binacchi
wrote:
> The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the
> Novatek NT35510-based panel family.
>
> Signed-off-by: Dario Binacchi
v4 looks very nice, thanks!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Mon, Jan 1, 2024 at 5:16 PM Dario Binacchi
wrote:
> The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the
> Novatek NT35510-based panel family.
>
> Signed-off-by: Dario Binacchi
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
init sequences are not OK in this driver, and not in general,
it is all the other drivers that are just unaware about what they are doing
and this driver actually isn't.
Yours,
Linus Walleij
for
sequence encoding with less open coded command issue
statements, by adding helpers to the DRM core, so if that is what
you want to do, then do that instead?
Yours,
Linus Walleij
> +- const: hydis,hva40wv1
> +- const: novatek,nt35510
> + items:
> +- const: frida,frd400b25025
> +- const: novatek,nt35510
You need a dash in from of each "items:" for that to work.
Yours,
Linus Walleij
;")
Signed-off-by: Linus Walleij
---
MAINTAINERS | 5 -
drivers/video/fbdev/Kconfig | 18 -
drivers/video/fbdev/Makefile| 1 -
drivers/video/fbdev/amba-clcd.c | 984
include/linux/amba/clcd-regs.h | 87
inclu
On Fri, Dec 8, 2023 at 4:48 PM Chris Morgan wrote:
> From: Chris Morgan
>
> The Powkiddy RG-ARC is a series of 2 handheld devices, each with a 4
> inch 480x640 display. Add support for the display.
>
> Signed-off-by: Chris Morgan
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
> is the expected register value.
>
> Fixes: 83b7a8e7e88e ("drm/panel/panel-sitronix-st7701: Parametrize voltage
> and timing")
>
> Signed-off-by: Chris Morgan
Good catch!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Dec 8, 2023 at 4:48 PM Chris Morgan wrote:
> From: Chris Morgan
>
> The RG-ARC panel is a panel specific to the Anbernic RG-ARC. It is 4
> inches in size (diagonally) with a resolution of 480x640.
>
> Signed-off-by: Chris Morgan
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
the FD performs an ioctl. Fix this by checking TGID.
>
> Fixes: 4230cea89cafb ("drm: Track clients by tgid and not tid")
> Signed-off-by: Lingkai Dong
Tested-by: Linus Walleij
Yours,
Linus Walleij
mailbox:
https://lore.kernel.org/dri-devel/pa6pr08mb107665920be9a96658cda04ce88...@pa6pr08mb10766.eurprd08.prod.outlook.com/
I'm seeing this as well (on Android).
Tvrko, Christian: can you look at this?
Will you apply it to the AMD tree for fixes if it looks OK
or does it go elsewhere?
Yours,
Linus Walleij
and drivers that use
dma-ranges for help:
Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml
drivers/pci/controller/pci-ixp4xx.c
Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml
drivers/pci/controller/pci-ftpci100.c
Yours,
Linus Walleij
he same for a certain SoC, e.g. compatible
"renesas,sh7751-intc"?
Then don't keep it in the device tree, just look it up per-soc from a
table in the driver.
Other than that it looks good to me.
Yours,
Linus Walleij
aintainer for that area of the kernel?
> Could you write a patch to do so?
Patch dim? Well my bash skills are a bit so-so. But I guess I could
learn it. But did you say there is already a prototype?
Yours,
Linus Walleij
On Tue, Nov 28, 2023 at 11:13 AM Neil Armstrong
wrote:
> On 28/11/2023 11:12, Neil Armstrong wrote:
> > Hi,
> >
> > On Tue, 28 Nov 2023 00:10:18 +0100, Linus Walleij wrote:
> >> This series reverts the attempts to fix the bug that went
> >> into v6.7-rc1
On Tue, Nov 28, 2023 at 9:30 AM Neil Armstrong
wrote:
> You can apply them now, or tell me if you want me to apply them.
Please apply them Neil (to drm-misc-fixes) order 2, 1, 3 for bisectability.
Yours,
Linus Walleij
On Tue, Nov 28, 2023 at 12:25 AM Laurent Pinchart
wrote:
> On Tue, Nov 28, 2023 at 12:10:18AM +0100, Linus Walleij wrote:
> > This series reverts the attempts to fix the bug that went
> > into v6.7-rc1 in commit 199cf07ebd2b
> > "drm/bridge: panel: Add a device link be
hinks
this is needed for it's devices, and yet no other bus/subsystem
does."
Link: https://lore.kernel.org/dri-devel/2023112739-willing-sighing-6bdd@gregkh/
Signed-off-by: Linus Walleij
---
drivers/base/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/co
...@mail.gmail.com/T/
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/bridge/panel.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 5e8980023407..e48823a4f1ed 100644
--- a/drivers/gpu/drm
This reverts commit 199cf07ebd2b0d41185ac79b895547d45610b681.
This patch creates bugs on devices where the DRM device is
the ancestor of the panel devices.
Attempts to fix this have failed because it leads to using
device core functionality which is questionable.
Reported-by: Linus Walleij
This series reverts the attempts to fix the bug that went
into v6.7-rc1 in commit 199cf07ebd2b
"drm/bridge: panel: Add a device link between drm device and panel device"
and then it reverts that patch as well.
Signed-off-by: Linus Walleij
---
Linus Walleij (3):
Revert "driv
sing
the issue so we can clear the original bug out of the way, take
a step back and fix this properly.
Yours,
Linus Walleij
On Mon, Nov 27, 2023 at 5:29 PM Maxime Ripard wrote:
> On Mon, Nov 27, 2023 at 05:03:53PM +0100, Linus Walleij wrote:
> > > Liu Ying (2):
> > > driver core: Export device_is_dependent() to modules
> > > drm/bridge: panel: Check device dependency before manag
e compiles even complete.
Yeah I know. I should buy a better computer.
Yours,
Linus Walleij
or dependent panel devices and hence relevant panel bridges
> fail to be attached. A real broken panel is "novatek,nt35510" defined
> in arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts as reported by
> Linus Walleij.
>
> Patch 1 exports device_is_dependent() to modules a
: 887878014534 ("drm/bridge: panel: Fix device link for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR")
> Fixes: 199cf07ebd2b ("drm/bridge: panel: Add a device link between drm device
> and panel device")
> Reported-by: Linus Walleij
> Closes:
> https://lore.kernel.org/lkml/c
confirm that device_link_add() returns NULL
> right after it calls device_is_dependent()?
>
> Does this patch fix the issue?
Yep it works!
You missed one device_link_del() instance on the errorpath.
Tested-by: Linus Walleij
Can you send it as a proper patch?
Yours,
Linus Walleij
quot;;
pinctrl-0 = <_default_mode>;
backlight = <>;
};
};
};
The DSI bridge is inside the display controller (MCDE) and the panel is
right inside the DSI bridge.
Suggestions welcome, I'm clueless why this happens.
Yours,
Linus Walleij
s is more formally correct indeed.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
kes perfect sense to me:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Mon, Oct 23, 2023 at 11:06 AM Dario Binacchi
wrote:
> Replace 'HFP' with 'HBP'.
>
> Fixes: 899f24ed8d3a ("drm/panel: Add driver for Novatek NT35510-based panels")
> Signed-off-by: Dario Binacchi
Patch applied!
Yours,
Linus Walleij
On Mon, Oct 30, 2023 at 8:24 AM John Watts wrote:
> SPI drivers needs their own list of compatible device IDs in order
> for automatic module loading to work. Add those for this driver.
>
> Signed-off-by: John Watts
> Reviewed-by: Jessica Zhang
Reviewed-by: Linus Walleij
On Mon, Oct 30, 2023 at 8:24 AM John Watts wrote:
> This display is extremely similar to the LTK035C5444T, but still has
> some minor variations in panel initialization.
>
> Signed-off-by: John Watts
> Reviewed-by: Jessica Zhang
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Mon, Oct 30, 2023 at 8:24 AM John Watts wrote:
> Many of these registers have a known name in the public datasheet.
> Document them as comments for reference.
>
> Signed-off-by: John Watts
> Reviewed-by: Jessica Zhang
This makes things better so:
Reviewed-by: Linus Walleij
Cong, Doug,
thanks for fixing this up, I'm very pleased with how it turned out.
Yours,
Linus Walleij
for this exact reason: so they can
have thumb, which is compact.
OK OK we definitely need command sequence tables in the core,
what we have now is each driver rolling its own which is looking bad.
Yours,
Linus Walleij
t;
> until we get some resolution about the binary size issue.
OK works for me:
Reviewed-by: Linus Walleij
Dough, if it looks OK to you too, can you apply the patches?
Yours,
Linus Walleij
By deprecation
and addition...) can we look into this?
I would say can we at least agree that before we merge one more
driver into this file, break out to subdrivers those that clearly have
an identifiable display controller and is thus reusable? From my
point of view I can just see the ili9882t so that's a good start.
Yours,
Linus Walleij
- Update compatible string & description to match marketing name
> - Remove unnecessary clock-names definition in ti,am62-gpu constraints
> - Document that GPU revision is discoverable
This looks good to me!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
; [1]:
> https://android.googlesource.com/kernel/tegra/+/refs/heads/android-tegra-dragon-3.18-oreo/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
>
> Signed-off-by: Diogo Ivo
That's a nice driver.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
nst: img,powervr-axe-1-16
any reason not to do this?
I asked about the relationship between these strings and the product
designations earlier I think :/
Yours,
Linus Walleij
ssed.
>
> I have at least confirmed that "allmodconfig" for arm64 doesn't fall
> on its face with this series. I haven't done a ton of other testing.
The series:
Reviewed-by: Linus Walleij
Please send out a non-RFC version, this is clearly the right thing to
do.
Yours,
Linus Walleij
efore.
> Thanks to Laurent for catching that
>
> Best regards
> Uwe
>
> Uwe Kleine-König (2):
> pwm: Manage owner assignment implicitly for drivers
> pwm: crc: Allow compilation as module and with COMPILE_TEST
Clearly the right thing to do! Nice patches.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
n
> possibly do is to save a few bytes of .text if a driver can be used both
> with and without it. Hence we remove of_match_ptr.
>
> Signed-off-by: Zhu Wang
Patch applied!
Yours,
Linus Walleij
n
> possibly do is to save a few bytes of .text if a driver can be used both
> with and without it. Hence we remove of_match_ptr.
>
> Signed-off-by: Zhu Wang
Patch applied!
Yours,
Linus Walleij
quot;command FF", I
am pretty sure it is clear what that does.)
As I pointed out in some other review, long term we want to support
things such as gamma correction for panels, and then this kind of
information will help greatly, even small pieces.
Yours,
Linus Walleij
On Wed, Jul 19, 2023 at 12:59 PM Luca Ceresoli
wrote:
> These variables are never referenced in the code.
>
> Signed-off-by: Luca Ceresoli
Patch applied and pushed to drm-misc-next.
Yours,
Linus Walleij
t: gpio: Explicitly set the direction of the
> GPIO")
> Signed-off-by: Liu Ying
The solutions seems fine.
Acked-by: Linus Walleij
Yours,
Linus Walleij
nces
I feel, bit this pattern is already in the driver so I guess it's OK.
Yours,
Linus Walleij
both vgacon and cyber2000fb?
Heh I tested this then walked out of the office for vacation.
But I can put a note in my calendar to test it when I return to
my equipment!
Yours,
Linus Walleij
are enabled now.
>
> To limit the amount of surprises on Arm, change the Kconfig default
> to the previously used 80x30 setting instead of the usual 80x25.
>
> Signed-off-by: Arnd Bergmann
Tested this before and after patch and it looks the same on the NetWinder.
Tested-by: Linus
s I would
certainly like to send the message that datasheets and proper
defines would be appreciated, and say it is also for their best, because
I mentioned proper gamma correction is possible if the driver author
just invest time and works with the DRM community and that should
be in their best in
defines instead of 0xff 0x98 0x82 0x01... but I'm late to the
show.
Yours,
Linus Walleij
certainly no hurry :D
Yours,
Linus Walleij
1 - 100 of 1266 matches
Mail list logo