Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
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 > > > OMAP3 support (it needs a workaround for a hardware bug) and > > > for automatic display rotation. They should get their own series, > > > once after everything has been moved to DRM panel API. I think > > > DRM panel conversion should happen _after_ this series, since > > > otherwise there is a high risk of bricking DSI support completely. > > > I already started a WIP branch for converting DSI to the DRM panel > > > API on top of this patchset. > > > > 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'll test it > > when I get the kernel booting. > > Great good to have these merged finally :) > > Hmm I wonder if some x15 models are affected by the SoC variant > changes queued in my fixes branch? I still don't see the patches in next-20190603 . Are they expected to be there, or should I use different tree? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* 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 > > > > > kernel > > > > > config. > > > > > > > > Strange that this is not affecting other x15? I think timer12 would > > > > be blocked on HS devices though? > > > > > > Seems that the kernel config affects. omap2plus_defconfig boots ok. > > > > OK, this line in your oops: > > > > Unable to handle kernel paging request at virtual address 5a5a5a5a > > > > Probably means we hit some slab poison with DEBUG_SLAB set. > > Looks like your config boots fine with DEBUG_SLAB disabled > > for me. > > > > As this only happens for timer12, I wonder if we're again > > hitting some uncompress issue with corrupted dtb. Changing > > u-boot ftdaddr higher up might possibly make it go away. > > Or else there's a bug elsewhere :) > > Oh but CM_WKUPAON_TIMER12_CLKCTRL has no CLKSEL option unlike > CM_WKUPAON_TIMER1_CLKCTRL. Below is one part of the fix, but > it seems like we're missing handling somewhere as trying to > get a non-existing clock should just produce -ENODEV type error. > > And the clksel should be just handled with assigned-clocks > in general, but I think we still need it there until we > have drivers/clocksource/ timer drivers updated to boot > using early_platform_device. OK found it, we have the clkctrl clock potentially return uninitialized data. I posted two fixes for the issue: [PATCH] clk: ti: clkctrl: Fix returning uninitialized data [PATCH] ARM: dts: Drop bogus CLKSEL for timer12 on dra7 Regards, Tony
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* 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.
> > >
> > > Strange that this is not affecting other x15? I think timer12 would
> > > be blocked on HS devices though?
> >
> > Seems that the kernel config affects. omap2plus_defconfig boots ok.
>
> OK, this line in your oops:
>
> Unable to handle kernel paging request at virtual address 5a5a5a5a
>
> Probably means we hit some slab poison with DEBUG_SLAB set.
> Looks like your config boots fine with DEBUG_SLAB disabled
> for me.
>
> As this only happens for timer12, I wonder if we're again
> hitting some uncompress issue with corrupted dtb. Changing
> u-boot ftdaddr higher up might possibly make it go away.
> Or else there's a bug elsewhere :)
Oh but CM_WKUPAON_TIMER12_CLKCTRL has no CLKSEL option unlike
CM_WKUPAON_TIMER1_CLKCTRL. Below is one part of the fix, but
it seems like we're missing handling somewhere as trying to
get a non-existing clock should just produce -ENODEV type error.
And the clksel should be just handled with assigned-clocks
in general, but I think we still need it there until we
have drivers/clocksource/ timer drivers updated to boot
using early_platform_device.
Regards,
Tony
8< ---
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -4450,8 +4450,6 @@
timer12: timer@0 {
compatible = "ti,omap5430-timer";
reg = <0x0 0x80>;
- clocks = <_clkctrl
DRA7_WKUPAON_TIMER12_CLKCTRL 24>;
- clock-names = "fck";
interrupts = ;
ti,timer-alwon;
ti,timer-secure;
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* 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 would > > be blocked on HS devices though? > > Seems that the kernel config affects. omap2plus_defconfig boots ok. OK, this line in your oops: Unable to handle kernel paging request at virtual address 5a5a5a5a Probably means we hit some slab poison with DEBUG_SLAB set. Looks like your config boots fine with DEBUG_SLAB disabled for me. As this only happens for timer12, I wonder if we're again hitting some uncompress issue with corrupted dtb. Changing u-boot ftdaddr higher up might possibly make it go away. Or else there's a bug elsewhere :) Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
On 28/05/2019 13.32, Tomi Valkeinen wrote: > On 28/05/2019 13:18, Tony Lindgren wrote: >> Strange that this is not affecting other x15? I think timer12 would >> be blocked on HS devices though? > > I don't know... I can't believe my x15 would be unique =). Can it be > something in the kernel config? u-boot? > > Peter should have the same A3. Peter, can you try with my config? It did not boot with your config. My config boots, I'm using SLUB. Flipping CONFIG_SLUB_DEBUG_ON to y and the kernel does not boot. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
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 would be blocked on HS devices though? Seems that the kernel config affects. omap2plus_defconfig boots ok. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
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/am5728.dtsi
@@ -31,3 +31,7 @@
_tm {
status = "disabled";
};
+
+ {
+ status = "disabled";
+};
OK we should disable it at the target-module level though. Interesting
that reading the revision register works with the above, or maybe you
still get some warning?
I don't see anything odd in the boot log with the above change. At least
no kernel WARNs, nor anything with grepping "timer", "err", or "warn".
I just verified with clean 5.2-rc2, that it doesn't boot, and with the
above change, boots.
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 would
be blocked on HS devices though?
I don't know... I can't believe my x15 would be unique =). Can it be
something in the kernel config? u-boot?
Peter should have the same A3. Peter, can you try with my config?
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* 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 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'll
> > > > > test it
> > > > > when I get the kernel booting.
> > > >
> > > > Great good to have these merged finally :)
> > > >
> > > > Hmm I wonder if some x15 models are affected by the SoC variant
> > > > changes queued in my fixes branch?
> > >
> > > This is what I see with earlycon, on linux-omap fixes branch. I think
> > > this looks
> > > similar to what I saw with dra76 _without_ the fixes.
> >
> > OK sounds like we need to use some different SoC specific .dtsi file,
> > is this maybe x15 rev c?
> >
> > You can detect which modules fail based on the module base address
> > for revision register seen with the following debug patch. Then
> > those need to be tagged with status = "disabled" at the module
> > level in the SoC specific dtsi file.
>
> [1.370609] ti-sysc 4ae2.target-module: probing device
>
> 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/am5728.dtsi
> @@ -31,3 +31,7 @@
> _tm {
>status = "disabled";
> };
> +
> + {
> + status = "disabled";
> +};
OK we should disable it at the target-module level though. Interesting
that reading the revision register works with the above, or maybe you
still get some warning?
> 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 would
be blocked on HS devices though?
Regards,
Tony
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
On 28/05/19 3:09 PM, 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 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'll test it
when I get the kernel booting.
Great good to have these merged finally :)
Hmm I wonder if some x15 models are affected by the SoC variant
changes queued in my fixes branch?
This is what I see with earlycon, on linux-omap fixes branch. I think this looks
similar to what I saw with dra76 _without_ the fixes.
OK sounds like we need to use some different SoC specific .dtsi file,
is this maybe x15 rev c?
You can detect which modules fail based on the module base address
for revision register seen with the following debug patch. Then
those need to be tagged with status = "disabled" at the module
level in the SoC specific dtsi file.
Tomi,
My first suspect would be rtc.
diff --git a/arch/arm/boot/dts/am5728.dtsi b/arch/arm/boot/dts/am5728.dtsi
index 82e5427ef6a9..17b1b1b4db92 100644
--- a/arch/arm/boot/dts/am5728.dtsi
+++ b/arch/arm/boot/dts/am5728.dtsi
@@ -31,3 +31,7 @@
_tm {
status = "disabled";
};
+
+ {
+ status = "disabled";
+};
Regards,
Keerthy
Regards,
Tony
8< --
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -2069,6 +2069,8 @@ static int sysc_probe(struct platform_device *pdev)
struct sysc *ddata;
int error;
+ dev_info(>dev, "probing device\n");
+
ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
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'll test > >> it > >> when I get the kernel booting. > > > > Great good to have these merged finally :) > > > > Hmm I wonder if some x15 models are affected by the SoC variant > > changes queued in my fixes branch? > > This is what I see with earlycon, on linux-omap fixes branch. I think this > looks > similar to what I saw with dra76 _without_ the fixes. OK sounds like we need to use some different SoC specific .dtsi file, is this maybe x15 rev c? You can detect which modules fail based on the module base address for revision register seen with the following debug patch. Then those need to be tagged with status = "disabled" at the module level in the SoC specific dtsi file. Regards, Tony 8< -- diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -2069,6 +2069,8 @@ static int sysc_probe(struct platform_device *pdev) struct sysc *ddata; int error; + dev_info(>dev, "probing device\n"); + ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL); if (!ddata) return -ENOMEM;
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
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'll test it >> when I get the kernel booting. > > Great good to have these merged finally :) > > Hmm I wonder if some x15 models are affected by the SoC variant > changes queued in my fixes branch? This is what I see with earlycon, on linux-omap fixes branch. I think this looks similar to what I saw with dra76 _without_ the fixes. [1.290771] Unable to handle kernel paging request at virtual address 5a5a5a5a [1.298222] pgd = (ptrval) [1.301002] [5a5a5a5a] *pgd= [1.304695] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [1.310158] Modules linked in: [1.313300] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc1-00016-g43069e68f162-dirty #7 [1.321979] Hardware name: Generic DRA74X (Flattened Device Tree) [1.328256] PC is at clk_hw_create_clk.part.33+0x8/0x94 [1.333632] LR is at sysc_notifier_call+0x98/0x138 [1.338558] pc : []lr : []psr: 0013 [1.345001] sp : eb8f7c78 ip : 5a5a5a5a fp : c0b3b538 [1.350374] r10: 0001 r9 : r8 : [1.355746] r7 : eaab8340 r6 : eaabea10 r5 : cffea79c r4 : [1.362459] r3 : cffea79c r2 : eaabc8c0 r1 : 5a5a5a5a r0 : eaabea10 [1.369174] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [1.376513] Control: 10c5387d Table: 8000406a DAC: 0051 [1.382422] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) [1.388599] Stack: (0xeb8f7c78 to 0xeb8f8000) [1.393077] 7c60: cffea79c [1.401493] 7c80: eaabea10 c04fb514 c0e76c6c fffd 0001 eaabea10 [1.409905] 7ca0: 0001 c015cee8 0001 eb8dfb80 eaabea10 c0e05148 [1.418319] 7cc0: c0e2e4f0 c015d684 eaabea10 [1.426732] 7ce0: eb93c810 c05b97e4 0fee2f56 0fee2f56 [1.435143] 7d00: eaabea00 eb93c810 efdbfd0c 0001 c078edb0 [1.443557] 7d20: efdbfcc0 c0e05148 c0e2e390 c078ef88 eb93ca8c [1.451972] 7d40: c0a39b64 eb93c810 eb93c88c eb93ca8c c0e05148 c091b0c4 eb93c810 c05c9aac [1.460386] 7d60: c0f13ba4 6013 c0a39b64 0fee2f56 c0a39b3c efdbfcc0 efdbfa3c c0a39b64 [1.468800] 7d80: c0e2e390 eb93c810 0001 c0a39b3c c078f2b8 0001 0fee2f56 [1.477213] 7da0: eaab8340 eaab8340 eb93c810 c0e05148 0001 0010 c04fc964 [1.485627] 7dc0: c0349714 c0e2e500 eb93c810 0001 efdbfa3c ea9dfd28 [1.494039] 7de0: 0001 0001 0003 0fee2f56 0001 eb93c810 c0e76c8c [1.502451] 7e00: c0e76c8c c0eb8f30 c05c00e8 eb93c810 c0f0f35c [1.510865] 7e20: c0f0f360 c05bdc04 c0e76c8c eb93c810 c0eaf2a0 eb93c810 [1.519278] 7e40: c0e76c8c c0e76c8c c0e05148 e000 c0d5b834 00d8 c0eaf2a0 c05be0b4 [1.527692] 7e60: c0a39d00 a013 c0eaf2a0 eb93c810 c0e76c8c c0e05148 e000 [1.536104] 7e80: c0d5b834 c05be450 c0e76c8c eb93c810 c05be4fc eb9380b4 c0e76c8c [1.544516] 7ea0: c05be458 c05bbc24 c0eaf2a0 eb8dfb58 eb9380b4 0fee2f56 c0e76c8c c0e76c8c [1.552928] 7ec0: ea9e4280 c0e85338 c05bcf68 c0b7aa98 c0e05148 c0d36b20 c0e76c8c [1.561343] 7ee0: c0e05148 c0d36b20 c05bf0a0 c0eaf2a0 c0e05148 c0d36b20 c0102f88 [1.569757] 7f00: c0c4e10c efd9a82f c015a900 eb8f7f14 c0d004a8 0006 [1.578171] 7f20: 0006 c0bc2e88 efd9a827 0fee2f56 [1.586583] 7f40: c0eaf2a0 c0d004a8 0006 0fee2f56 c0d770ec 0007 c0d5b854 c0eca080 [1.594997] 7f60: c0eca080 c0d01208 0006 0006 c0d004a8 c09145e0 [1.603411] 7f80: c09145e0 [1.611823] 7fa0: c09145e8 c01010e8 [1.620237] 7fc0: [1.628651] 7fe0: 0013 [1.637074] [] (clk_hw_create_clk.part.33) from [] (sysc_notifier_call+0x98/0x138) [1.646656] [] (sysc_notifier_call) from [] (notifier_call_chain+0x2c/0xa0) [1.655612] [] (notifier_call_chain) from [] (blocking_notifier_call_chain+0x50/0x68) [1.665461] [] (blocking_notifier_call_chain) from [] (device_add+0x3bc/0x628) [1.674685] [] (device_add) from [] (of_platform_device_create_pdata+0x90/0xbc) [1.683997] [] (of_platform_device_create_pdata) from [] (of_platform_bus_create+0x1a0/0x328) [1.694558] [] (of_platform_bus_create) from [] (of_platform_populate+0x7c/0x108) [1.704046] []
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* 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 > > OMAP3 support (it needs a workaround for a hardware bug) and > > for automatic display rotation. They should get their own series, > > once after everything has been moved to DRM panel API. I think > > DRM panel conversion should happen _after_ this series, since > > otherwise there is a high risk of bricking DSI support completely. > > I already started a WIP branch for converting DSI to the DRM panel > > API on top of this patchset. > > 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'll test it > when I get the kernel booting. Great good to have these merged finally :) Hmm I wonder if some x15 models are affected by the SoC variant changes queued in my fixes branch? Regards, Tony
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
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 OMAP3 support (it needs a workaround for a hardware bug) and for automatic display rotation. They should get their own series, once after everything has been moved to DRM panel API. I think DRM panel conversion should happen _after_ this series, since otherwise there is a high risk of bricking DSI support completely. I already started a WIP branch for converting DSI to the DRM panel API on top of this patchset. 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'll test it when I get the kernel booting. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
