Re: [PATCH V2 3/3] video: exynos_dp: Use the generic PHY driver
On 12:35 Fri 28 Jun , Felipe Balbi wrote:
On Fri, Jun 28, 2013 at 04:18:23PM +0900, Jingoo Han wrote:
Use the generic PHY API instead of the platform callback to control
the DP PHY. The 'phy_label' field is added to the platform data
structure to allow PHY lookup on non-dt platforms.
Signed-off-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/video/exynos_dp.txt| 17 ---
drivers/video/exynos/exynos_dp_core.c | 118
++--
drivers/video/exynos/exynos_dp_core.h |2 +
include/video/exynos_dp.h |6 +-
4 files changed, 15 insertions(+), 128 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..a8320e3 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -1,17 +1,6 @@
The Exynos display port interface should be configured based on
the type of panel connected to it.
-We use two nodes:
- -dp-controller node
- -dptx-phy node(defined inside dp-controller node)
-
-For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
- -reg:
- Base address of DP PHY register.
- -samsung,enable-mask:
- The bit-mask used to enable/disable DP PHY.
-
For the Panel initialization, we read data from dp-controller node.
Required properties for dp-controller:
-compatible:
@@ -67,12 +56,6 @@ SOC specific portion:
interrupt-parent = combiner;
clocks = clock 342;
clock-names = dp;
-
- dptx-phy {
- reg = 0x10040720;
- samsung,enable-mask = 1;
- };
I've an issue here you break dt compatibilty
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 15:42 Thu 23 May , Stephen Warren wrote: On 05/19/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: ... how a pin can not have mux? Well, if that's the way HW is designed, that's just the way it is. There are certainly pins on Tegra which don't have a mux in HW, but have some configuration options such as drive strength that can be configured. on Samsung it's not the case I mean on at91 we have fixed mux and configurable mux On Tegra IIRC it's the same Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 11:28 Tue 21 May , Tomasz Figa wrote:
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD6 periph A MCI0_DA5 with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD7 periph A MCI0_DA6 with pullup, conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE; /* PB5 gpio multidrive I2C2 clock */ };
};
so we could share the c code too
OK. After thinking about it a bit more recently, I think your solution
might be fine.
However there is one thing I'm worried about. As far as I remember, when
setting a function (mux selector), pinctrl core calls pin_request() to
request all pins of the group for the device which requested the
configuration.
Now if we use hogs to set up default configuration of pins, all of them
would get requested for the pin controller and then further pin control
configuration done by device drivers would fail. This is why I wanted to
allow setting pinmux and pinconf separately, without one requiring
another.
I undertatnd you use default config for power management optimisation, is it
not?
so you need to set different state in the device instead of using hogs.
default, sleep, etc..
I get an other issue too I have the same pin requested more than one time by
multiple driver.
As thoses pins are used for external memory interface, but they have the same
config. The current pinctrl implementation does not allow share pin.
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
PULL_UP (1 0): indicate this pin need a pull up.
MULTIDRIVE (1 1): indicate this pin need to be configured as
multidrive. DEGLITCH(1 2): indicate this pin need
deglitch.
PULL_DOWN (1 3): indicate this pin need a pull down.
DIS_SCHMIT (1 4): indicate this pin need to disable schmit
trigger. DEBOUNCE(1 16): indicate this pin need debounce.
DEBOUNCE_VAL(0x3fff 17): debounce val.
today I was planning to update the binding to allow to this
instead of writing this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_NONE
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
we will write this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
so a pin can have 3 or more parameter
so as a generic binding only the 3 first will be namdatory (bank
pinnp
muxid) the rest will driver specific
for power down I plan to define an other node
dbgu {
pinctrl_dbgu_sleep: dbgu_sleep-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_GPIO,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_DOWN;
};
};
I'm afraid this won't work for Samsung SoCs. In our case normal and
power down settings are completely unrelated, i.e. stored in separate
registers and one doesn't affect another (a system controller
automatically switches between normal and power down settings when
entering or leaving low power modes, like SoC-level suspend).
and?
Pin configuration node on Exynos SoCs will need 7 values for each pin in
samsung,pins property, just like in following example:
mmc0 {
mmc0_bus1: mmc0-bus1 {
pins = GPA0 4 SFN3 PULL_UP DRV4 PDN_IN PDN_PULL_UP;
};
/* ... */
};
Now if I just want to enable pull-up for a single pin, I will have to add
following node:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE;
};
no you will not
foo {
pins = GPK1 2 NONE PULL_UP;
};
how a pin can not have mux?
while with current bindings I can simply omit properties that I don't care
about (or are going to be set up correctly by other means - e.g.
gpio_direction_input() or request_irq(), ending with following node:
foo {
samsung,pins = gpk1-2;
samsung,pin-pud = 3;
};
except here you will 100s of NODE which we do NOT want in the dtb
This is all I need to configure for simple things like open-drain
interrupt lines.
Another thing is that we're using one driver for many SoCs, which have
different variants of the controller. So for example some of them don't
have driver strength configuration (S3C24xx, S3C64xx), other don't have
power down mode configuration (S3C24xx) and even some of the banks on some
SoCs don't support particular type of configuration (alive banks of SoCs
same on at91 some IP have less feature
and some SoC have the IP/die but not the same pins package
the key point is to share the pin DT handling between at91, ST and Samsung
ofcourse all the IP will have more or less parameter per pin but the basic is
the same for DT and C code
= S3C64xx don't have power down mode configuration, because they are
always on).
on at91 I've x banks of registers to handle each gpio bank
on ST with have same situation but the controller work the same way at
the end
so we need to factorise code
Personally I'd prefer a solution with separate property for each
parameter, because it's much more flexible and allows shorter lines,
making device tree sources more readable.
we already discuss this on the ML the one property perline will endup
with 100s of node if not 1000s so we all do agree we do not want this
in the DT
Could you point me to this discussion, please? I'd really like to take a
look.
you have to search this on the dt ML, it was about the clk bindings IIRC and
agree on this at Prague durring kernel Summit
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 11:46 Sun 19 May , Tomasz Figa wrote:
On Sunday 19 of May 2013 11:17:36 Jean-Christophe PLAGNIOL-VILLARD wrote:
PULL_UP (1 0): indicate this pin need a pull up.
MULTIDRIVE (1 1): indicate this pin need to be
configured as
multidrive. DEGLITCH(1 2): indicate this pin need
deglitch.
PULL_DOWN (1 3): indicate this pin need a pull down.
DIS_SCHMIT (1 4): indicate this pin need to disable
schmit
trigger. DEBOUNCE(1 16): indicate this pin need
debounce.
DEBOUNCE_VAL(0x3fff 17): debounce val.
today I was planning to update the binding to allow to this
instead of writing this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A
AT91_PINCTRL_NONE
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
we will write this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
so a pin can have 3 or more parameter
so as a generic binding only the 3 first will be namdatory (bank
pinnp
muxid) the rest will driver specific
for power down I plan to define an other node
dbgu {
pinctrl_dbgu_sleep: dbgu_sleep-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_GPIO,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_DOWN;
};
};
I'm afraid this won't work for Samsung SoCs. In our case normal
and
power down settings are completely unrelated, i.e. stored in
separate
registers and one doesn't affect another (a system controller
automatically switches between normal and power down settings when
entering or leaving low power modes, like SoC-level suspend).
and?
Pin configuration node on Exynos SoCs will need 7 values for each pin
in samsung,pins property, just like in following example:
mmc0 {
mmc0_bus1: mmc0-bus1 {
pins = GPA0 4 SFN3 PULL_UP DRV4 PDN_IN PDN_PULL_UP;
};
/* ... */
};
Now if I just want to enable pull-up for a single pin, I will have to
add following node:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE;
};
no you will not
foo {
pins = GPK1 2 NONE PULL_UP;
};
OK, this will work in case of one pin, but if you need two it starts to
become problematic. Let's look at an example:
We have two pins for which we don't need to specify power down mode
settings (e.g. they are in alive banks):
foo {
pins = GPK1 2 NONE PULL_UP,
GPK1 3 NONE PULL_UP;
};
as done for cs-gpios
After compilation you will get just a series of u32 values, like
foo {
pins = 1 2 255 3 1 3 255 3;
};
How are you going to distinguish such setup with:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE,
GPK1 3 NONE PULL_UP NONE NONE NONE;
};
which translates to
foo {
pins = 1 2 255 3 255 255 255 1 3 255 3 255 255 255;
};
I mean, you don't know where one entry ends and another starts, if you
allow to left out some values.
on gpios we can do so, I want to have the same feature here
how a pin can not have mux?
I don't always want to change the mux. Sometimes I just want to change one
of the other parameters. For example, I don't want to switch the pin to
interrupt mode on driver probe (it is a separate pin mux value), but
rather after the trigger type gets configured, which is done by
request_irq() based on trigger flags.
so request the same
while with current bindings I can simply omit properties that I don't
care about (or are going to be set up correctly by other means - e.g.
gpio_direction_input() or request_irq(), ending with following node:
foo {
samsung,pins = gpk1-2;
samsung,pin-pud = 3;
};
except here you will 100s of NODE which we do NOT want in the dtb
Is this really an issue?
just one example
slow down the boot
We are already using this method to describe really complex boards (not
necessarily in mainline) and we don't have any problems.
This is all I need to configure for simple things like open-drain
interrupt lines.
Another thing is that we're using one driver for many SoCs, which have
different variants of the controller. So for example some
Re: Pulls and drive strengths in the pinctrl world
On 14:17 Fri 17 May , Tomasz Figa wrote:
Hi Jean-Christophe,
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD6 periph A MCI0_DA5 with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD7 periph A MCI0_DA6 with pullup, conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE; /* PB5 gpio multidrive I2C2 clock */ };
};
so we could share the c code too
I'd have a question with regard to AT91 bindings.
Using Samsung bindings we don't need to specify all configuration options
for a pin, only those that are relevant for the platform. Do your bindings
allow this?
on at91 we have this too we just put NONE, and I'm planning to allow to drop
the last option too (not yet implement)
Apparently AT91 has less configurable things and those available are
usually always configured together so it's not a problem. But on our SoCs
we have a bit more of them:
- function (input, output, special functions)
- pull-down/-up
- driver strength
- power down mode function (input, output low, output high, retention)
- power down mode pull-down/-up
- one could argue that default output value could be set this way as well,
by adding samsung,pin-value property.
on Atmel you have
first a pin need to be muxed as a gpio or a function name periph
depending on the SoC we can have up to 4 function mode + gpio
then each pin have feature that are independent of the mux function
Bits used for CONFIG: (4th parameter)
PULL_UP (1 0): indicate this pin need a pull up.
MULTIDRIVE (1 1): indicate this pin need to be configured as multidrive.
DEGLITCH(1 2): indicate this pin need deglitch.
PULL_DOWN (1 3): indicate this pin need a pull down.
DIS_SCHMIT (1
Re: Pulls and drive strengths in the pinctrl world
On 16:57 Sat 18 May , Tomasz Figa wrote:
On Saturday 18 of May 2013 10:18:47 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 14:17 Fri 17 May , Tomasz Figa wrote:
Hi Jean-Christophe,
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like
my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late
now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors
from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread.
It
looks like hogs in the Samsung pinctrl bingings end up looking
like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD6 periph A MCI0_DA5
with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD7 periph A MCI0_DA6 with pullup,
conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE; /* PB5 gpio multidrive I2C2 clock
*/ };
};
so we could share the c code too
I'd have a question with regard to AT91 bindings.
Using Samsung bindings we don't need to specify all configuration
options for a pin, only those that are relevant for the platform. Do
your bindings allow this?
on at91 we have this too we just put NONE, and I'm planning to allow to
drop the last option too (not yet implement)
Apparently AT91 has less configurable things and those available are
usually always configured together so it's not a problem. But on our
SoCs we have a bit more of them:
- function (input, output, special functions)
- pull-down/-up
- driver strength
- power down
Re: Pulls and drive strengths in the pinctrl world
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now here
(2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging wouldn't
solve the problem indeed. (It might have to be fixed on pinctrl-samsung
first, as last time I tried to use it, it caused some errors from pinctrl
core, but haven't time to track them down, as it wasn't anything important
at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A AT91_PINCTRL_NONE
/* PD9 periph A MCI0_CK */
AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD0 periph A MCI0_CDA with pullup */
AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */
};
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD2 periph A MCI0_DA1 with pullup */
AT91_PIOD 3 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD 4 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3 with pullup */
};
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD5 periph A MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */
AT91_PIOD 6 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD6 periph A MCI0_DA5 with pullup, conflicts with TIOB0, PWML2 */
AT91_PIOD 7 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD7 periph A MCI0_DA6 with pullup, conlicts with TCLK0, PWMH3 */
AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup, conflicts
with PWML3 */
};
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio multidrive I2C2 data */
AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE;/* PB5 gpio multidrive I2C2 clock */
};
};
so we could share the c code too
Best Regards,
J,
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
pinctrl-names = default;
pinctrl-0 = pina pinp pinx;
};
That pinctrl-0 property could get rather large (hard to write/maintain,
unwieldy) if it needs to set up lots of different configurations. That's
why I made the equivalent Tegra bindings be:
pinctrl {
pins_default {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
};
pinctrl-names = default;
pinctrl-0 = pins_default;
};
The extra level within the pinctrl configuration node (pins_default
here) makes the pinctrl-0 property a lot easier to write, and the
Re: [PATCH v2] ARM: Kconfig: let ARM9TDMI and ARM7TDMI invisible.
On Apr 25, 2013, at 1:46 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Apr 24, 2013 at 12:20:24PM +0800, Chen Gang wrote: If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible, but in fact, only AT91X40 need ARM7TDMI, so need not let them visible. I'll apply it myself this evening. Can I add: Tested-by: Chen Gang gang.c...@asianux.com you add it mine too Tested-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Best Regards, J. to it? ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using randconfig
On 12:53 Wed 17 Apr , Arnd Bergmann wrote:
On Wednesday 17 April 2013, Will Deacon wrote:
arm-linux-gnu-gcc -Wp,-MD,arch/arm/vfp/.vfphw.o.d -nostdinc -isystem
/usr/lib/gcc/arm-linux-gnueabi/4.7.1/include
-I/root/linux-next/arch/arm/include -Iarch/arm/include/generated
-Iinclude -I/root/linux-next/arch/arm/include/uapi
-Iarch/arm/include/generated/uapi -I/root/linux-next/include/uapi
-Iinclude/generated/uapi -include
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian
-Iarch/arm/mach-s5pv210/include -Iarch/arm/plat-samsung/include
-D__ASSEMBLY__ -mabi=apcs-gnu -mno-thumb-interwork -marm
-D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm9tdmi -include
asm/unified.h -Wa,-mfpu=softvfp+vfp -mfloat-abi=soft-c -o
arch/arm/vfp/vfphw.o arch/arm/vfp/vfphw.S
compiling err:
arch/arm/vfp/vfphw.S: Assembler messages:
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM
mode `mrrc p11,3,r0,r1,c0'
arch/arm/vfp/vfphw.S:295: Error: selected processor does not support ARM
mode `mrrc p11,3,r0,r1,c1'
The problem here is that you've ended up targetting a platform (s5pv210)
that selects CPU_V7. VFP is then subsequently selected, but CONFIG_MMU=n, so
7TDMI and 9TDMI (v4 CPUs, no VFP) are selectable. Selecting either of those,
causes these warnings.
Unfortunately, I'm not sure how best to fix this. Most of the !MMU CPUs are
tied to a particular board (lots of `if ARCH_INTEGRATOR' predicates), but we
don't want to do that for 7tdmi.
If we could enforce the strict exclusion of {= ARMv5} and {ARMv6+} in the
Kconfig, that would solve your problem.
I have not tried to get no-MMU kernels to build in general. I think the way
it should be done is to not offer any user-selectable CPU types at all but
always select the CPU from the board.
For randconfig tests, I would recommend turning on CONFIG_MMU unconditionally
using an appropriate KCONFIG_ALLCONFIG= file.
The alternative is to use the patch below, but it may be incomplete: I could
not find anything other than AT91x40 in the kernel that actually has an
ARM7TDMI or ARM9TDMI.
Arnd
diff --git a/arch/arm/mach-at91/Kconfig.non_dt
b/arch/arm/mach-at91/Kconfig.non_dt
index 6c24985..dc972e1 100644
--- a/arch/arm/mach-at91/Kconfig.non_dt
+++ b/arch/arm/mach-at91/Kconfig.non_dt
@@ -47,6 +47,7 @@ config ARCH_AT91X40
select ARCH_USES_GETTIMEOFFSET
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
+ select CPU_ARM7TDMI
endchoice
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 84af266..c5e4ef0 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -6,7 +6,6 @@ comment Processor Type
# ARM7TDMI
config CPU_ARM7TDMI
- bool Support ARM7TDMI processor
whith the bool type at least
depends on !MMU
select CPU_32v4T
select CPU_ABRT_LV4T
@@ -56,7 +55,6 @@ config CPU_ARM740T
# ARM9TDMI
config CPU_ARM9TDMI
- bool Support ARM9TDMI processor
depends on !MMU
select CPU_32v4T
select CPU_ABRT_NOMMU
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ODROID-X: dts: Add board dts file for ODROID-X
On 17:56 Mon 17 Dec , Olof Johansson wrote:
On Mon, Dec 17, 2012 at 11:55 AM, Dongjin Kim tobet...@gmail.com wrote:
Add initial dtb file for Hardkernel's ODROID-X board based on EXYNOS4412
SoC.
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos4412-odroidx.dts | 52
++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4412-odroidx.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ca6fb8e..3355af9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -45,6 +45,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5440-ssdk5440.dtb \
exynos4412-smdk4412.dtb \
+ exynos4412-odroidx.dtb \
Please add them alphabetically, so before smdk.
we need to drop the \ \ stuff it will end with merge conflict
as if you add 2 dtb at the end you will end with 2 patch that touch the same
previous line
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
new file mode 100644
index 000..786ddd7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -0,0 +1,52 @@
+/*
+ * Hardkernel's Exynos4412 based ODROID-X board device tree source
+ *
+ * Copyright (c) 2012-2013 Dongjin Kim tobet...@gmail.com
Are you from the future?
+ *
+ * Device tree source file for Hardkernel's ODROID-X board which is based
on
+ * Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ exynos4412.dtsi
+
+/ {
+ model = Hardkernel ODROID-X board based on Exynos4412;
+ compatible = samsung,exynos4412;
It should have a more specific compatible value first, i.e.
hardkernel,odroid-x or similar.
+ memory {
+ reg = 0x4000 0x4000;
+ };
+
+ chosen {
+ bootargs =root=/dev/mmcblk0p3 rw console=ttySAC1,115200
init=/sbin/init delay=2;
Bootargs should be passed in from u-boot, don't specify them in the
static device tree.
why not we can choose to have a default cmdline and even usit as a complement
of the bootloader one
it's up to the dts maintainer to choose
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ODROID-X: dts: Add board dts file for ODROID-X
On 22:14 Mon 17 Dec , Olof Johansson wrote:
On Mon, Dec 17, 2012 at 10:00 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 17:56 Mon 17 Dec , Olof Johansson wrote:
On Mon, Dec 17, 2012 at 11:55 AM, Dongjin Kim tobet...@gmail.com wrote:
Add initial dtb file for Hardkernel's ODROID-X board based on EXYNOS4412
SoC.
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos4412-odroidx.dts | 52
++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4412-odroidx.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ca6fb8e..3355af9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -45,6 +45,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5440-ssdk5440.dtb \
exynos4412-smdk4412.dtb \
+ exynos4412-odroidx.dtb \
Please add them alphabetically, so before smdk.
we need to drop the \ \ stuff it will end with merge conflict
as if you add 2 dtb at the end you will end with 2 patch that touch the same
previous line
..which is why the dts files should be added alphabetically instead of
just appended to the list.
we need to drop this \
and use this syntax and keep ordered
dtb-$() +=
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
new file mode 100644
index 000..786ddd7
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -0,0 +1,52 @@
+/*
+ * Hardkernel's Exynos4412 based ODROID-X board device tree source
+ *
+ * Copyright (c) 2012-2013 Dongjin Kim tobet...@gmail.com
Are you from the future?
+ *
+ * Device tree source file for Hardkernel's ODROID-X board which is
based on
+ * Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ exynos4412.dtsi
+
+/ {
+ model = Hardkernel ODROID-X board based on Exynos4412;
+ compatible = samsung,exynos4412;
It should have a more specific compatible value first, i.e.
hardkernel,odroid-x or similar.
+ memory {
+ reg = 0x4000 0x4000;
+ };
+
+ chosen {
+ bootargs =root=/dev/mmcblk0p3 rw console=ttySAC1,115200
init=/sbin/init delay=2;
Bootargs should be passed in from u-boot, don't specify them in the
static device tree.
why not we can choose to have a default cmdline and even usit as a
complement
of the bootloader one
it's up to the dts maintainer to choose
The chance of having a valid generic command line that will work for
everyone with that hardware is fairly small, especially on more
generic systems that might have a regular distro installed on them.
this does not hurt anyone 99% of the people will overwrite you can just see as
a cmdline example
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/33] Use common macro to define resources
On 09:38 Wed 25 Apr , Heiko Stübner wrote: Hi, Am Mittwoch, 25. April 2012, 06:19:39 schrieb Jean-Christophe PLAGNIOL- VILLARD: On 09:42 Wed 25 Apr , Tushar Behera wrote: There are some helper macros (DEFINE_RES_XXX) for defining resource structures. This patchset migrates all the earlier resource definitions (within Samsung specific code base) to use these macros. In some cases, it was not possible to use DEFINE_RES_IRQ() macro because of usage of additional flags. In those cases, DEFINE_RES_NAMED() macro is used instead. The patches are rebased on top of Kukjin's for-next branch at this commit. d0ee53a Merge branch 'next/board-samsung' into for-next is this really necessary as we switch to DT this code will be droped As far as I know legacy SoCs are allowed to keep being non-DT and I don't see the older Samsung SoCs (especially the S3C24XX ones) changing to DT anytime soon, as they don't see any new development but only bug fixes currently. for my point of view it's cosmetics change it is, but it also makes the code more readable we get comment from Linus to do not do cosmetic changes so if it work well I'll not touch it Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/33] Use common macro to define resources
On 09:42 Wed 25 Apr , Tushar Behera wrote: There are some helper macros (DEFINE_RES_XXX) for defining resource structures. This patchset migrates all the earlier resource definitions (within Samsung specific code base) to use these macros. In some cases, it was not possible to use DEFINE_RES_IRQ() macro because of usage of additional flags. In those cases, DEFINE_RES_NAMED() macro is used instead. The patches are rebased on top of Kukjin's for-next branch at this commit. d0ee53a Merge branch 'next/board-samsung' into for-next is this really necessary as we switch to DT this code will be droped for my point of view it's cosmetics change Arnd what do you think? Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/17] ARM: mark const init data with __initconst instead of __initdata
On 23:12 Thu 29 Mar , Uwe Kleine-König wrote: As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Cc: Andrew Victor li...@maxim.org.za Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Russell King li...@arm.linux.org.uk Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Kukjin Kim kgene@samsung.com Cc: Sascha Hauer ker...@pengutronix.de Cc: Shawn Guo shawn@linaro.org Cc: Lennert Buytenhek ker...@wantstofly.org Cc: Nicolas Pitre n...@fluxnic.net Cc: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: David Brown dav...@codeaurora.org Cc: Daniel Walker dwal...@fifo99.com Cc: Bryan Huntsman bry...@codeaurora.org Cc: Tony Lindgren t...@atomide.com Cc: Barry Song baohua.s...@csr.com Cc: Andrew Lunn and...@lunn.ch Cc: Lucas De Marchi lucas.demar...@profusion.mobi Cc: linux-arm-ker...@lists.infradead.org Cc: davinci-linux-open-sou...@linux.davincidsp.com Cc: linux-samsung-soc@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: linux-o...@vger.kernel.org --- arch/arm/mach-at91/board-dt.c |2 +- arch/arm/mach-at91/clock.c|2 +- for at91 Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On 16:28 Tue 22 Nov , Stephen Warren wrote:
Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org
wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Sorry to jump in late here, but I wasn't aware of this thread.
I don't necessarily agree with that. Describing the HW doesn't necessarily
mean that each device needs to describe what pinmux pins it uses; one
could quite easily have the pinmux describe what settings the various
pins should have and which drivers will use those pins. That would map
very well to the pinctrl subsystem's mapping table, and at least Tegra's
existing pinmux tables, which are both just a big array of settings which
end up getting provided to drivers.
I'll try and track down the rest of this thread and catch up though...
I agreee here
as example on at91 I try to found a good way to let the macb driver to ask the
pin configuration
so in my mind i do not need put all pins in each board but in the dtsi and
then in the drivers just said
pins = mii;
or
pins = rmii;
or if I want to use the alternative config
pins = mii_alt;
or
pins = rmii_alt;
and then in the dtsi I describe the pin used for those configs
which is soc specifific not board
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] ARM: Removing ARCH_S5PC100
On 12:36 Wed 18 May , Yauhen Kharuzhy wrote: On Wed, May 18, 2011 at 05:44:03PM +0900, Kukjin Kim wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: HI, Hi, why do you remove it? Thanks for your concerns :) I think it's rather premature to decide it at this time. So this is dropped at this moment...but as a note, I will implement this into other samsung stuff next time :) I think that we should implement SoC support with more unified way _before_ removing working code, not after. agreed for my point of view NACK to remove working code Russell do you agree? Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
