From: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
To: "ludovic.desroches"
<ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
Jean-Christophe PLAGNIOL-VILLARD
<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>,
Sylwester Nawrocki
<sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
n.voss-+umVssTZoCsb1SvskN2V4Q@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters
Date: Mon, 3 Sep 2012 09:51:18 +0200 [thread overview]
Message-ID: <50446176.6080604@atmel.com> (raw)
In-Reply-To: <50445B11.5050601-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On 09/03/2012 09:24 AM, ludovic.desroches :
> Le 09/01/2012 11:10 AM, Jean-Christophe PLAGNIOL-VILLARD a écrit :
>> On 22:47 Fri 31 Aug , Sylwester Nawrocki wrote:
>>> On 08/31/2012 04:51 PM, Nicolas Ferre wrote:
>>>>>> diff --git a/arch/arm/mach-at91/at91rm9200.c
>>>>>> b/arch/arm/mach-at91/at91rm9200.c
>>>>>> index f2112f9..0bc91e5 100644
>>>>>> --- a/arch/arm/mach-at91/at91rm9200.c
>>>>>> +++ b/arch/arm/mach-at91/at91rm9200.c
>>>>>> @@ -187,7 +187,7 @@ static struct clk_lookup
>>>>>> periph_clocks_lookups[] = {
>>>>>> CLKDEV_CON_DEV_ID("pclk", "ssc.0",&ssc0_clk),
>>>>>> CLKDEV_CON_DEV_ID("pclk", "ssc.1",&ssc1_clk),
>>>>>> CLKDEV_CON_DEV_ID("pclk", "ssc.2",&ssc2_clk),
>>>>>> - CLKDEV_CON_DEV_ID(NULL, "at91_i2c",&twi_clk),
>>>>>> + CLKDEV_CON_DEV_ID(NULL, "at91rm9200_i2c",&twi_clk),
>>>>> use i2c-xxx as on other drivers
>>>>>
>>>>> and I do not like to have platform_device_id
>>>>
>>>> Me, I like it and find this implementation very elegant.
>>>>
>>>>> as we need to touch the driver to add a new soc
>>>>
>>>> So what? We still keep the compatibility if the new SoC has it
>>>> compatibility assured with previous revision: there is nothing to
>>>> modify.
>>>
>>> I agree. The driver would need to be touched to support new SoC only if
>>> the IP there have had some differences, which would have needed to be
>>> resolved anyway.
>>>
>>>>> please use platform data
>>>
>>> Using platform data for the dt platforms would have been more
>>> troublesome,
>>> wouldn't it ? I like Ludovic's approach which handles both: dt and
>>> non-dt
>>> cases in uniform way from the driver's POV.
>> no you will describe it via DT as done on all the other drivers
>>>
>>>> No, it does not have to be exposed to the user: these data are highly
>>>> dependent on the actual hardware (IP revision in fact). So, no need to
>>>> mess with platform data.
>> no I really see no point on these list of platform_id it's does not
>> look more
>> nice just more huggly to have x names. This is at the end the same as
>> passing
>> platform data via soc info (add_xx or dtsi)
>>
>> And here you just do the same as cpu_is via names.
>>
>> The driver need to read IP revision instead
>>
>
> At the beginning it was planned to do this but:
> - a new SoC, with a new IP version lead to update the driver also
> - with the MCI driver which uses IP version, I have some cases where
> using the version was not enough, a SoC approach would be better. For
> instance, the IP version tells that we can use PDC feature but PDC is
> not connected.
Absolutely. Nikolaus and you have summarized clearly the situation.
I think there is a consensus here.
So, we can move to a v2 patch series...
Bye,
--
Nicolas Ferre
next prev parent reply other threads:[~2012-09-03 7:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-31 9:21 [PATCH 0/8] i2c: at91: cleanup and dt support ludovic.desroches
2012-08-31 9:21 ` [PATCH 1/8] i2c: at91: use managed resources ludovic.desroches
[not found] ` <1346404884-18451-2-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:52 ` Voss, Nikolaus
[not found] ` <1346404884-18451-1-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-08-31 9:21 ` [PATCH 2/8] i2c: at91: add warning about transmission issues for some devices ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w
[not found] ` <1346404884-18451-3-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:54 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 4/8] ARM: at91: do not configure at91sam9g10 twi pio as open-drain ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w
[not found] ` <1346404884-18451-5-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:57 ` Voss, Nikolaus
2012-09-06 4:57 ` Warner Losh
2012-08-31 9:23 ` ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w
2012-08-31 9:23 ` [PATCH 5/8] i2c: at91: add dt support to i2c-at91 ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w
[not found] ` <1346405029-18539-1-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:58 ` Voss, Nikolaus
2012-08-31 9:24 ` [PATCH 6/8] ARM: at91: add clocks for I2C DT entries ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w
[not found] ` <1346405058-18580-1-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:58 ` Voss, Nikolaus
2012-08-31 9:24 ` [PATCH 8/8] ARM: dts: add twi nodes for atmel boards ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w
2012-08-31 14:42 ` Jean-Christophe PLAGNIOL-VILLARD
[not found] ` <20120831144228.GC23867-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2012-08-31 15:07 ` Nicolas Ferre
[not found] ` <5040D31E.8040306-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-01 9:12 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-03 7:55 ` [PATCH 0/8] i2c: at91: cleanup and dt support Nicolas Ferre
2012-08-31 9:21 ` [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters ludovic.desroches
2012-08-31 14:29 ` Jean-Christophe PLAGNIOL-VILLARD
[not found] ` <20120831142944.GA23867-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2012-08-31 14:51 ` Nicolas Ferre
[not found] ` <5040CF80.8060201-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-08-31 20:47 ` Sylwester Nawrocki
[not found] ` <504122D3.70507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-09-01 9:10 ` Jean-Christophe PLAGNIOL-VILLARD
[not found] ` <20120901091054.GA17540-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2012-09-02 17:21 ` Sylwester Nawrocki
[not found] ` <504395B1.2040203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-09-06 4:54 ` Warner Losh
2012-09-03 6:16 ` Voss, Nikolaus
2012-09-03 7:24 ` ludovic.desroches
[not found] ` <50445B11.5050601-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 7:51 ` Nicolas Ferre [this message]
[not found] ` <1346404884-18451-4-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:55 ` Voss, Nikolaus
2012-08-31 9:24 ` [PATCH 7/8] ARM: dts: add twi nodes for atmel SOCs ludovic.desroches
2012-08-31 14:41 ` Jean-Christophe PLAGNIOL-VILLARD
[not found] ` <20120831144105.GB23867-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
2012-08-31 14:46 ` ludovic.desroches
2012-08-31 14:56 ` Nicolas Ferre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50446176.6080604@atmel.com \
--to=nicolas.ferre-aife0yeh4naavxtiumwx3w@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org \
--cc=n.voss-+umVssTZoCsb1SvskN2V4Q@public.gmane.org \
--cc=plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org \
--cc=sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).