From: ludovic.desroches@atmel•com (ludovic.desroches)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters
Date: Mon, 3 Sep 2012 09:24:01 +0200 [thread overview]
Message-ID: <50445B11.5050601@atmel.com> (raw)
In-Reply-To: <20120901091054.GA17540@game.jcrosoft.org>
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.
> Best Regards,
> J.
>
>
Regards
Ludovic
next prev parent reply other threads:[~2012-09-03 7:24 UTC|newest]
Thread overview: 32+ 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 at atmel.com
2012-08-31 9:21 ` [PATCH 1/8] i2c: at91: use managed resources ludovic.desroches at atmel.com
2012-09-03 5:52 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 2/8] i2c: at91: add warning about transmission issues for some devices ludovic.desroches at atmel.com
2012-09-03 5:54 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters ludovic.desroches at atmel.com
2012-08-31 14:29 ` Jean-Christophe PLAGNIOL-VILLARD
2012-08-31 14:51 ` Nicolas Ferre
2012-08-31 20:47 ` Sylwester Nawrocki
2012-09-01 9:10 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-02 17:21 ` Sylwester Nawrocki
2012-09-06 4:54 ` Warner Losh
2012-09-03 6:16 ` Voss, Nikolaus
2012-09-03 7:24 ` ludovic.desroches [this message]
2012-09-03 7:51 ` Nicolas Ferre
2012-09-03 5:55 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 4/8] ARM: at91: do not configure at91sam9g10 twi pio as open-drain ludovic.desroches at atmel.com
2012-09-03 5:57 ` Voss, Nikolaus
2012-08-31 9:23 ` ludovic.desroches at atmel.com
2012-08-31 9:23 ` [PATCH 5/8] i2c: at91: add dt support to i2c-at91 ludovic.desroches at atmel.com
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 at atmel.com
2012-09-03 5:58 ` Voss, Nikolaus
2012-08-31 9:24 ` [PATCH 7/8] ARM: dts: add twi nodes for atmel SOCs ludovic.desroches at atmel.com
2012-08-31 14:41 ` Jean-Christophe PLAGNIOL-VILLARD
2012-08-31 14:46 ` ludovic.desroches
2012-08-31 14:56 ` Nicolas Ferre
2012-08-31 9:24 ` [PATCH 8/8] ARM: dts: add twi nodes for atmel boards ludovic.desroches at atmel.com
2012-08-31 14:42 ` Jean-Christophe PLAGNIOL-VILLARD
2012-08-31 15:07 ` Nicolas Ferre
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
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=50445B11.5050601@atmel.com \
--to=ludovic.desroches@atmel$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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