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.
>> 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.
>> 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.)
>> 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.
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:
#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,
};
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
