From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
To: 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: Sat, 1 Sep 2012 11:10:54 +0200 [thread overview]
Message-ID: <20120901091054.GA17540@game.jcrosoft.org> (raw)
In-Reply-To: <504122D3.70507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
Best Regards,
J.
WARNING: multiple messages have this Message-ID (diff)
From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters
Date: Sat, 1 Sep 2012 11:10:54 +0200 [thread overview]
Message-ID: <20120901091054.GA17540@game.jcrosoft.org> (raw)
In-Reply-To: <504122D3.70507@gmail.com>
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
Best Regards,
J.
next prev parent reply other threads:[~2012-09-01 9:10 UTC|newest]
Thread overview: 65+ 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 ` ludovic.desroches at atmel.com
2012-08-31 9:21 ` [PATCH 1/8] i2c: at91: use managed resources ludovic.desroches
2012-08-31 9:21 ` ludovic.desroches at atmel.com
[not found] ` <1346404884-18451-2-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:52 ` Voss, Nikolaus
2012-09-03 5:52 ` Voss, Nikolaus
2012-08-31 9:21 ` [PATCH 3/8] i2c: at91: use an id table for SoC dependent parameters ludovic.desroches
2012-08-31 9:21 ` ludovic.desroches at atmel.com
2012-08-31 14:29 ` Jean-Christophe PLAGNIOL-VILLARD
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
2012-08-31 14:51 ` Nicolas Ferre
[not found] ` <5040CF80.8060201-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-08-31 20:47 ` Sylwester Nawrocki
2012-08-31 20:47 ` Sylwester Nawrocki
[not found] ` <504122D3.70507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-09-01 9:10 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
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
2012-09-02 17:21 ` Sylwester Nawrocki
[not found] ` <504395B1.2040203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-09-06 4:54 ` Warner Losh
2012-09-06 4:54 ` Warner Losh
2012-09-03 6:16 ` Voss, Nikolaus
2012-09-03 6:16 ` Voss, Nikolaus
2012-09-03 7:24 ` ludovic.desroches
2012-09-03 7:24 ` ludovic.desroches
[not found] ` <50445B11.5050601-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 7:51 ` Nicolas Ferre
2012-09-03 7:51 ` Nicolas Ferre
[not found] ` <1346404884-18451-4-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:55 ` Voss, Nikolaus
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 9:24 ` ludovic.desroches at atmel.com
2012-08-31 14:41 ` Jean-Christophe PLAGNIOL-VILLARD
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:46 ` ludovic.desroches
2012-08-31 14:56 ` Nicolas Ferre
2012-08-31 14:56 ` Nicolas Ferre
[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
2012-08-31 9:21 ` ludovic.desroches at atmel.com
[not found] ` <1346404884-18451-3-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:54 ` Voss, Nikolaus
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
2012-08-31 9:21 ` ludovic.desroches at atmel.com
[not found] ` <1346404884-18451-5-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:57 ` Voss, Nikolaus
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 ` ludovic.desroches at atmel.com
2012-08-31 9:23 ` [PATCH 5/8] i2c: at91: add dt support to i2c-at91 ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w
2012-08-31 9:23 ` ludovic.desroches at atmel.com
[not found] ` <1346405029-18539-1-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:58 ` Voss, Nikolaus
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
2012-08-31 9:24 ` ludovic.desroches at atmel.com
[not found] ` <1346405058-18580-1-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
2012-09-03 5:58 ` Voss, Nikolaus
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 9:24 ` ludovic.desroches at atmel.com
2012-08-31 14:42 ` Jean-Christophe PLAGNIOL-VILLARD
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
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-01 9:12 ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-03 7:55 ` [PATCH 0/8] i2c: at91: cleanup and dt support Nicolas Ferre
2012-09-03 7:55 ` 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=20120901091054.GA17540@game.jcrosoft.org \
--to=plagnioj-sclmfoaustbwk0htik3j/w@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=n.voss-+umVssTZoCsb1SvskN2V4Q@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.