Hi Mark,
On 16/08/2013 19:20, Mark Rutland wrote:
Hi Benoit,
On Fri, Aug 16, 2013 at 03:15:57PM +0100, Benoit Cousson wrote:
Hi Gururaja,
On 16/08/2013 13:36, Hebbar, Gururaja wrote:
The syntax of compatible property in DT is to mention the Most specific
match to most generic match.
Since AM335x is the platform with latest IP revision, add it 1st in
the device id table.
I don't understand why? The order should not matter at all.
I've tried to follow the thread you had with Mark on the v2, but AFAIK,
you've never answered to his latest question.
Moreover, checking the differences between the Davinci and the am3352
RTC IP, I would not claim that both are compatible.
Sure you can use the am3352 with the Davinci driver, but you will lose
the wakeup functionality without even being notify about that.
Could you describe the wakeup functionality, and how it differs between
the am3352-rtc and the da830-rtc?
AFAIK, da830-rtc does not have that functionality at all. This is
something that was added to the am3352-rtc.
As I understand it, the am3352 functionality is a superset of the da830
functionality. You can use the old driver, and get some functionality,
or use the new driver and get it all.
Mmm, what your are saying now seems to make sense to me as well. So I'm
even more confused :-)
That means that am3352-rtc is compatible with da830. As long as the
kernel first checks for am3352-rtc, there will be *no* loss of
functionality. All this does is enable older kernels to use the hardware
in some fashion, and given the older kernel didn't have support for the
am3352-rtc features, this is a *gain* in functionality, not a loss.
For my point of view, compatible mean that the HW will still be fully
functional with both versions of the driver, which is not the case here.
What? A driver for any entry in the compatible list should be able to
drive the hardware to *some* level of functionality. We list from
most-specific to most-general to allow a graceful degradation from fully
supported to bare minimum functionality.
OK, but where is it written in the DT spec that this is what the
compatible is supposed to mean?
I'm quoting it again:
"
The compatible property value consists of one or more strings that
define the specific programming model for the device. This list of
strings should be used by a client program for device driver selection.
The property value consists of a concatenated list of null terminated
strings, from most specific to most general. They allow a device to
express its compatibility with a family of similar devices, potentially
allowing a single device driver to match against several devices.
"
The graceful degradation or the loss of functionality is not something
that I really understand in that text.
Anyway, I'm probably too tired... I'll go back home, and think about
that after the week-end.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
