On Tue, Nov 18, 2014 at 04:39:31PM -0500, Lennart Sorensen wrote:
> On Tue, Nov 18, 2014 at 10:17:13PM +0100, Gilles Chanteperdrix wrote:
> > It is not just TI. I believe all vendor forks have the same issue:
> > they are not written by people well versed into paying attention to
> > the kind of issue you have to pay attention to with Linux. Once
> > their patches get reviewed, of course they improve. But this takes a
> > lot of time, and for some drivers, they will not even make the
> > effort.
>
> Certainly true.
>
> > That being said, the last two vendor forks I used are for TI DM8148,
> > and Xilinx Zynq, and I have to admit that the TI DM8148 fork code
> > is much much worse than the Xilinx one.
> >
> > Ok, it seems the TI mainline maintainers are less sloppy, the kernel
> > compiles and boot on both platforms. Less sloppy only because on my
> > OMAP3 board, the USB controller does not get initialized.
>
> TI seems to be on a 'Get it mainlined' kick lately, so perhaps they are
> being more careful as a result.
>From what I was told by someone who knew someone who talked to
someone, this was actually actually a two step process (I do not
know whether this changed).
An team did the work that went into the kernel fork that was
delivered to customers, with rapid delivery date as the priority
goal.
Then in a second time, a different team started writing the code
that went into mainline, I am not even sure it used the code of the
first team.
>
> > Anyway, this is not a good solution, this is clearly something that
> > nobody tests, thre is no reason to expect it what we would expect to
> > dot.
>
> I see this 'hack' in the omap timer code:
>
> +#ifdef CONFIG_IPIPE
> + if (ipipe) {
> + u32 l;
> +
> + l = __raw_readl(timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> + l = (0x3 << 8) | (l & (1 << 5)) | (0x1 << 3) | (1 << 2);
> + __raw_writel(l, timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
> + }
> +#endif
>
> Sure would be nice if someone had actually defined what those bits are,
> although it appears to be setting wakeup on, and idle mode to 'no idle',
> and I didn't look up the 5 and 8 bits yet.
I did that. And I prefer explicit bit numbers, because they match
the datasheet, which is the ultimate reference.
With code relying on defines, you have to trust the define names to
match what you think they do. And I have learned to never trust
identifier names, so I want to check the datasheet anyway, and the
defines do not help, because now instead of having just 4 fields to
check from the same line of code in the documentation of one
register, you have to find the 4 fields definitions in the
middle of a whole bunch of definitions in a separate header file,
and move back and forth.
So, the bottom line is, while I understand the values of defines to
provide the same name to the same bit, when used in several places,
as would be the case for software bitfield, I do not see the value
of it for register values.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
