On Sun, 29 Jun 2014 22:35:11 +0100 Russell King - ARM Linux linux@arm.linux.org.uk wrote:

There is actually a cubox regression which has yet to be tracked down. Running with my kernel (which is not-DT based) runs perfectly. With DT, HDMI output can be unstable.

Russell,

What is this HDMI problem with DT?

I am running a DT based kernel on my Cubox for more than 1 year and the only problem I have is a random black screen at startup time, and this black screen problem also exists with the old non-DT kernels from SolidRun.

On Mon, 30 Jun 2014 09:49:18 +0100 Russell King - ARM Linux linux@arm.linux.org.uk wrote:

The problem is that the picture appears for about a second, then goes black for maybe a couple of seconds, then reappears for about a second and this cycle repeats. Rebooting into the DT kernel doesn't fix it. Rebooting back into the non-DT kernel does fix it. Then if you boot back into the DT kernel it's back again. Boot back into the non-DT kernel and it's again fixed.

I have compared register settings for the Si5351, LCD controllers and the TDA998x between the non-DT and DT versions, and can find no differences there. Yet, DT kernels are the only kernels which exhibit this behaviour. Non-DT kernels (which I've run continuously including many reboots) for the last two years have *never* shown this problem.

I have also verified that the HDMI clock is correct. The problem occurs at both 1080p and 720p resolutions (which are the two that are used during boot - I have the kernel using 720p, and Xorg uses 1080p.)

I should also point out that in both cases, it is the _same_ kernel binary (3.15) that I'm running - the DT test case just has the DT blob attached whereas the non-DT case boots without (and therefore falls back to the old platform stuff.)

Have you declared the LCD clock in dove.dtsi?

lcdclk: fixed-clock { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <400000000>; };

On 06/29/2014 11:35 PM, Russell King - ARM Linux wrote:

On Sun, Jun 29, 2014 at 10:59:47PM +0200, Andrew Lunn wrote:

...

This patchset removes arch/arm/mach-kirkwood and arch/arm/mach-dove. These SoCs are now supported in arch/arm/mach-mvebu using device tree.

Change the dependencies for a number of drivers, either to use ARCH_MVEBU where the drivers are generic, or MACH_KIRKWOOD and MACH_DOVE where the drivers are specific to a SoC.

Andrew Lunn (13): ARM: Kirkwood: Remove mach-kirkwood ARM: Dove: Remove mach-dove

There is actually a cubox regression which has yet to be tracked down. Running with my kernel (which is not-DT based) runs perfectly. With DT, HDMI output can be unstable.

One of the problems is that it's /very/ difficult to reproduce, but it is reproducable. I've seen it on two days over many reboots, and I've proved it by switching back and forth. DT sometimes suffers from the problem, whereas non-DT /never/ does.

Sebastian is aware of this, and as yet we haven't found a solution, nor have we found a way to reliably reproduce it.

I am aware of the issue but have not been able to reproduce it. Also, we have no /official/ non-DT CuBox support in mainline Linux at all. I understand that removing non-DT mach-dove currently is not your most preferred patch but from a mainline POV, mach-dove isn't actively used. The three officially supported boards have been converted to DT months ago and haven't received any TLC since then, so I doubt they are used by anyone.

My current impression of the issue is that it is more related with driver load order/missing delays for clocks/ignoring IP behavior on clock rate change or something like it.

Can you give a /rough/ schedule for your plans to sort out your private branches? If we can all investigate the issue with the same code basis, I am sure we can make DT dove behave the same way non-DT dove seems to be.

Sebastian

On 06/30/2014 02:43 PM, Russell King - ARM Linux wrote:

On Mon, Jun 30, 2014 at 02:15:58PM +0200, Sebastian Hesselbarth wrote:

...

Can you give a /rough/ schedule for your plans to sort out your private branches? If we can all investigate the issue with the same code basis, I am sure we can make DT dove behave the same way non-DT dove seems to be.

As you will be aware, that is an unreasonable question. I have no idea what so ever how long it will take to sort out my private branches, because it doesn't depend all that much on me.

Russell,

we all know about the pain to get things into mainline especially when it touches different sub-systems. That is why I was asking for /your/ plans, so we can think of ways to deal with mach-dove removal and your pending patches.

For example, I've had fully working audio on the Cubox for 18+ months, but there's a big problem getting it into mainline. First it was the lack of co-operation from the ASoC maintainers. Then it was the ASoC maintainers accepting Jean-Francois patches (which really torpedoed my efforts.) And the final problem which makes it totally impossible is that pushing the DPCM stuff will completely break the DT based kirkwood ASoC stuff which got pushed in.

I suspect that the PMU work I did has also been torpedoed because of no one in the mvebu circles has really thought about how to deal properly with the overlapping registers for the PMU, hwmon and RTC.

Of course we thought about it. But as you are dealing with different SoCs at a time, we also have to care about some more SoCs than just Dove. And, of course, we also run out of spare time to prepare proper patches over and over again. I really /know/ that if you send patches, they are well thought and well tested, so I basically postpone work on that if I know you are working on it.

My current idea of PMU register space is to have a DT provided regmap but again, there are patches floating around but currently that regmap helpers are still WIP. FWIW, if you look at dove pinctrl, we did a last-minute patch for the PMU regs - just because you mentioned a concern, so we really care about your opinion. The fact that it is not solved is pure lack of time.

Right now, I have 250 patches in my Cubox tree against a base of 3.15 plus the original set of changes. And no, I'm *not* going to be stupid enough to publish the tree because of the non-GPL license header(s) on various files in the Vivante code base.

Exactly that increasing amount of (valuable) patches makes it more and more difficult for you and us to reproduce any issues. All I am asking for is: if you don't push that branch for good reason, try to split off at least some patches. Hunting issues like the HDMI thing with 250 patches off, really isn't going to work well.

I'm actually on the point of just giving up with mainlike on the Cubox because of this kind of crap, and the extreme difficulty to get any kind of progress on this stuff - and I'm seeing a growing number of patches on the Cubox-i side of things, the mainline churn on mach-dove is becoming a /big/ problem.

So... if you want to remove mach-dove, then I'll just add to my cubox tree an entire revert of it. Especially as DT does not work properly here and non-DT does.

Nobody wants you to revert any cubox patches! Honestly, I repeatedly said that /although/ I cannot reproduce the issue on my (mainline) branch, I still /agree/ that there may be issues. But as long as I cannot reproduce it, I cannot dig into it.

To put it another way: "Especially for me DT does work properly here and non-DT does not". Let's just try to reduce the gap between mainline and your branch incrementally.

And I really don't buy your "it's down to the timing" explanation - because (a) switching from 720p to 1080p reprograms the clock chain right from the Si5351, which is no different to what happens on initial bring up, and (b) I've measured the HDMI clock which is derived from this chain and it is correct and unmodulated.

I didn't say I *know* it is 'timing', but neither I do buy "it's because of DT". I said it may be related with init order and ignoring clock stable requirements. I've written Si5351 driver from an Application Note that is not very noisy about dynamic configuration, there are no checks for stable clocks at all.

Anyway, I still offer my time to hunt the HDMI issue: If we agree on some way to share your code or you provide some binaries I can reproduce the issue with, it will be a small step forward.

Sebastian

On 06/30/2014 04:25 PM, Russell King - ARM Linux wrote:

On Mon, Jun 30, 2014 at 03:22:58PM +0200, Sebastian Hesselbarth wrote:

...

Of course we thought about it. But as you are dealing with different SoCs at a time, we also have to care about some more SoCs than just Dove. And, of course, we also run out of spare time to prepare proper patches over and over again. I really /know/ that if you send patches, they are well thought and well tested, so I basically postpone work on that if I know you are working on it.

My current idea of PMU register space is to have a DT provided regmap but again, there are patches floating around but currently that regmap helpers are still WIP. FWIW, if you look at dove pinctrl, we did a last-minute patch for the PMU regs - just because you mentioned a concern, so we really care about your opinion. The fact that it is not solved is pure lack of time.

Nothing has changed on the PMU patches since I posted them, because they're based on 3.15 and there's been no changes there.

I offered to deal with mainlining them end of April, you never replied. I know that if you dislike something you answer, but it is hard to tell if silence means agreement.

I am not going to waste any time preparing patches just to get a NAK.

...

Exactly that increasing amount of (valuable) patches makes it more and more difficult for you and us to reproduce any issues. All I am asking for is: if you don't push that branch for good reason, try to split off at least some patches. Hunting issues like the HDMI thing with 250 patches off, really isn't going to work well.

Right, so what I have against mainline right now in my tree is:

• two SPI patches, which have been taken by Mark
• one long term core ARM patch adding optimised memset/memcpy IO operations
• the PMU stuff
• BMM (already published in git form)
• Vmeta (already published in git form)
• ASoC cleanup patches, which Mark took last week.

What isn't visible is the stuff which converts Armada DRM to component support, along with the TDA998x driver (and it sounds like the TI LCDC people may end up blocking that effort). This is necessary to convert it to DT support. However, this depends on the component helper, and that's where there's a blocking problem.

I sent out a bunch of patches last week, with a request for help from the Exynos people. So far, that has only attracted one relatively minor comment from the iMX people. I can't move forwards with the Armada DRM until this is sorted. Neither can I move forward with the TDA998x driver.

As for the ASoC stuff which you avoided commenting on, let me repeat that _that_ stuff is now totally dead and can /never/ be merged into mainline without breaking the existing ASoC kirkwood support. In that case, it's not like I wasn't sending the patches out, because I had been... so everyone was aware of what was going on there, but I guess converting stuff to DT in ways that totally fuck over other patches is what now happens in the kernel.

If you are talking about "Kirkwood ASoC updates", you got a Tested-by from Andrew even before I read your patches. And besides, just because I am interested in Dove does not mean I just swallowed the whole Linux API knowledge. I simply avoided commenting on it, because there is /nothing/ I can add to it.

Really, I know you do dig down to the bottom of every subsystem you are working with but I simply cannot. Just because I don't have the time for it.

What I think you're missing is that for those of us who want to have a platform fully supported, the choice has been non-DT until relatively recently. We're now at the point where the DT support on Dove has matured to the point where it's relatively easy to end up with a fully functional (but not necessarily bug free) setup with DT. It's at the sweet spot where you can switch between DT and non-DT and preserve that functionality... but as soon as we get there we want to rip out the old stuff.

Oh, ok.. you think it is "me" and "us"? It is you who actually want to use Dove and me just wanting a DT representation for it?

It is not my fault that your patches are blocked by others. I can offer help to track down the issue, but I am not going to be your scapegoat.

Let me put that another way: it's at the point where those of us who have been using non-DT support can start moving the remaining drivers over to a DT environment without any functional loss.

What I'm trying to get you to understand is that leaving the old stuff behind for a little while longer is beneficial - while those who have been running crippled DT based setups for the last year don't care about having full support, there are those who do.

Ok, let's have mach-dove for a little longer, fine with me.

Of course, there's another solution to this. I stay with my present 3.15 kernel for ever. That basically bars me from sending any further patches. It also means that I stop maintaining TDA998x and Armada DRM, and you will have to take those over, which means you get the additional workload from those. Is that what you really want?

What I really want is to stop that blackmailing with giving up on sending patches. It will be a huge loss if you do and many have said that in the past.

If it is really me who upsets you because you feel I am blocking your patches, just ignore my comments. Jason will happily pick them up just because you signed them off.

Sebastian

The Cubox is the /only/ ARM platform I have which is a capable media player, and I'm trying not to have it screwed by this kind of crap.

On 06/30/2014 06:56 PM, Russell King - ARM Linux wrote:

On Mon, Jun 30, 2014 at 05:35:49PM +0200, Sebastian Hesselbarth wrote:

...

On 06/30/2014 04:25 PM, Russell King - ARM Linux wrote:

...

Nothing has changed on the PMU patches since I posted them, because they're based on 3.15 and there's been no changes there.

I offered to deal with mainlining them end of April, you never replied. I know that if you dislike something you answer, but it is hard to tell if silence means agreement.

I am not going to waste any time preparing patches just to get a NAK.

That's because I am quite prepared to work on them _if_ there is a way forward. You've already said that changing things like hwmon and rtc is a work in progress to convert them to regmap. That's great, but in order to progress these myself, I need *visibility* of that work, and there is zero visibility of that.

So, we are on the same boat. For the HDMI issue, I also need visibility to add any more ideas how to deal with it. Just provide me the binaries, I see if I can at least reproduce the issue.

...

...

As for the ASoC stuff which you avoided commenting on, let me repeat that _that_ stuff is now totally dead and can /never/ be merged into mainline without breaking the existing ASoC kirkwood support. In that case, it's not like I wasn't sending the patches out, because I had been... so everyone was aware of what was going on there, but I guess converting stuff to DT in ways that totally fuck over other patches is what now happens in the kernel.

If you are talking about "Kirkwood ASoC updates", you got a Tested-by from Andrew even before I read your patches. And besides, just because I am interested in Dove does not mean I just swallowed the whole Linux API knowledge. I simply avoided commenting on it, because there is /nothing/ I can add to it.

No I am not - and those are the patches which I referred to as having been already taken by Mark into his tree. The patch I'm referring to which can never be merged now is the one which I replied to Jean Francois just now - and if you read through it, you'll understand why - that's because it /totally/ breaks the simple DT bindings that are now established - independently - for Kirkwood stuff.

And I stopped discussing the pros and cons of the simple DT binding as soon as I realized that my comments had no impact on the way it will be implemented. I am not responsible for the binding.

...

...

What I think you're missing is that for those of us who want to have a platform fully supported, the choice has been non-DT until relatively recently. We're now at the point where the DT support on Dove has matured to the point where it's relatively easy to end up with a fully functional (but not necessarily bug free) setup with DT. It's at the sweet spot where you can switch between DT and non-DT and preserve that functionality... but as soon as we get there we want to rip out the old stuff.

Oh, ok.. you think it is "me" and "us"? It is you who actually want to use Dove and me just wanting a DT representation for it?

It is not my fault that your patches are blocked by others. I can offer help to track down the issue, but I am not going to be your scapegoat.

Right, and removing the non-DT support and screwing people like me who have out of tree patches is good for MVEBU development because... (complete the sentence with a damned good reason.)

...ranting at people not jumping into review and testing is.

...

...

What I'm trying to get you to understand is that leaving the old stuff behind for a little while longer is beneficial - while those who have been running crippled DT based setups for the last year don't care about having full support, there are those who do.

Ok, let's have mach-dove for a little longer, fine with me.

Great, that's all I ask. I'm trying as fast as I can to push stuff out - I'm not being anywhere close to idle about it - but it takes time to deal with the updates from each merge window and such like, work out what has been accepted, which patches need to be revised, and do all the testing that's necessary before trying to get some more out. Oh, and port some more of the patches over to be mainline-based.

I would've preferred to be clear of the ASoC stuff 12 months ago, and we all know why that was a big problem.

...

What I really want is to stop that blackmailing with giving up on sending patches. It will be a huge loss if you do and many have said that in the past.

It's not blackmail. It's reality. If the kernel becomes too much hassle to deal with, then volunteers will walk away from it - that's almost a fact of life.

Right. And since I am one of those volunteers, I can tell you that some specific attitude in dealing with people is definitely reducing the willingness to stick with it.

I constantly offered to spend my spare time for hunting the issue but only received ranting.

Even with DT support, I'm nowhere near being "DT clean" on the Cubox - I need this as a minimum to do "special" stuff there:

Sure, nobody said that DT is feature complete. But you'd have to do the same on mainline non-DT dove as there has never been support for the cubox.

If it helps us tracking down the HDMI issue, we can have below setup for DT dove and get rid of it incrementally.

I am sure, Andrew can drop removing mach-dove removal from the patches and we can continue improving Dove mainline.

Sebastian

#include <linux/of_platform.h> #include <asm/hardware/cache-tauros2.h> #include "clock.h"

static struct resource armada_drm_resources[] = { DEFINE_RES_MEM(0, 0), };

static const char *armada_drm_devices[4];

static const struct platform_device_info armada_drm_dev_info __initconst = { .name = "armada-drm", .id = -1, .res = armada_drm_resources, .num_res = ARRAY_SIZE(armada_drm_resources), .data = armada_drm_devices, .size_data = sizeof(armada_drm_devices), };

static struct platform_device cubox_spdif = { .name = "kirkwood-spdif-audio", .id = 1, };

static const struct platform_device_info cubox_spdif_dit __initconst = { .name = "spdif-dit", .id = -1, };

static void __init cubox_reserve(void) { phys_addr_t phys;

    dove_reserve();

    /* Steal 32MB for the drm framebuffers */
    phys = arm_memblock_steal(SZ_32M, SZ_2M);
    armada_drm_resources[0].start = phys;
    armada_drm_resources[0].end = phys + SZ_32M - 1;

}

static void __init cubox_dt_init(void) { struct device_node *node; struct platform_device *pdev; int i;

    pr_info("Dove 88AP510 SoC\n");

#ifdef CONFIG_CACHE_TAUROS2 tauros2_init(0); #endif dove_init_pmu();

    BUG_ON(mvebu_mbus_dt_init());
    of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);

    dove_devclks_init();
    dove_gpu_init();
    dove_bmm_init();

    for (i = 0, node = NULL; (node = of_find_compatible_node(node, NULL, "marvell,dove-lcd")) != NULL; ) {
            if (!of_device_is_available(node))
                    continue;
            pdev = of_find_device_by_node(node);
            if (pdev)
                    armada_drm_devices[i++] = dev_name(&pdev->dev);
    }
    armada_drm_devices[i++] = NULL;
    platform_device_register_full(&armada_drm_dev_info);

    platform_device_register_full(&cubox_spdif_dit);
    platform_device_register(&cubox_spdif);

}

static const char * const cubox_dt_compat[] = { "solidrun,cubox", NULL };

DT_MACHINE_START(DOVE_DT, "Marvell Dove (Cubox)") .dt_compat = cubox_dt_compat, .reserve = cubox_reserve, .map_io = dove_map_io, .init_machine = cubox_dt_init, .restart = dove_restart, };

...

If you are talking about "Kirkwood ASoC updates", you got a Tested-by from Andrew even before I read your patches. And besides, just because I am interested in Dove does not mean I just swallowed the whole Linux API knowledge. I simply avoided commenting on it, because there is /nothing/ I can add to it.

No I am not - and those are the patches which I referred to as having been already taken by Mark into his tree. The patch I'm referring to which can never be merged now is the one which I replied to Jean Francois just now - and if you read through it, you'll understand why - that's because it /totally/ breaks the simple DT bindings that are now established - independently - for Kirkwood stuff.

Hi Russell

Are you referring to http://www.spinics.net/lists/arm-kernel/msg328068.html

Andrew

So, what do we do now with support for compressed audio streams via SPDIF on kirkwood hardware? As far as I can see, it's no longer possible and mainline kernels will never support this. Please tell me I'm wrong...

Well, it would of been nice if you had made a comment to either v1 or v2 of my patchset saying this is going to cause problems for some devices.

So i will go look at your patch to add frontend and backend and see what it means for the current DT binding. The nice thing about kirkwood (and Dove) is, there is no uboot with DT support. Hence nobody is flashing there DT blob. They are always using appended DT. So i'm not against changing the binding. And it has only been in the kernel for one cycle, so i doubt there are too many users at the moment.

Andrew

On 30 Jun 03:25 PM, Russell King - ARM Linux wrote: [..]

Right, so what I have against mainline right now in my tree is:

• two SPI patches, which have been taken by Mark
• one long term core ARM patch adding optimised memset/memcpy IO operations
• the PMU stuff
• BMM (already published in git form)
• Vmeta (already published in git form)
• ASoC cleanup patches, which Mark took last week.

What isn't visible is the stuff which converts Armada DRM to component support, along with the TDA998x driver (and it sounds like the TI LCDC people may end up blocking that effort). This is necessary to convert it to DT support. However, this depends on the component helper, and that's where there's a blocking problem.

I sent out a bunch of patches last week, with a request for help from the Exynos people. So far, that has only attracted one relatively minor comment from the iMX people. I can't move forwards with the Armada DRM until this is sorted. Neither can I move forward with the TDA998x driver.

I'm not sure I understand why tilcdc people are an obstacle for the component stuff, other than the lack of responsiveness. In any case, if you have some tilcdc or tda998x patches and you need help with the mainline process, feel free to ask.

I've been doing some tilcdc work lately, and I'd be happy to help you with that.

Do you plan to change the devicetree binding? While the current one works fine, it has several deficiencies, and it would be great to sort them out before the whole platform becomes obsolete.

Really, if you need help and if you think I can handle it, just drop me a line and I'll see what I can do.