Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Tony Lindgren]

* Linus Walleij <linus.wall...@linaro.org> [151209 05:14]:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
...

> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.

For omap:

Acked-by: Tony Lindgren <t...@atomide.com>
--
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/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Tony Lindgren]

* Laurent Pinchart  [151012 14:17]:
> Hello,
> 
> While working on regulators, GPIOs and DT I noticed that many of our DT source
> files incorrectly describe fixed regulators. The common error patterns are
> 
> - Usage of the undefined (and never parsed) enable-active-low property
> - Usage of the enable-active-high property without specifying an enable GPIO
> - Typos in the enabl GPIO property name (gpios instead of gpio)
> - Mismatch between the enable-active-high property (or the lack thereof) and
>   the enable GPIO flags
> 
> This patch series fixes those issues in all the DT sources after locating the
> errors using the following script.
> 
> --
> #!/bin/sh
> 
> echo $1
> cat $1 | awk '
> BEGIN {
>   open_drain = 0;
>   active_high = 0;
>   gpio = 0;
>   flags = 0;
> }
> 
> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
>   name = ary[1];
> }
> 
> /compatible.*"regulator-fixed"/ {
>   found = 1;
> }
> 
> /enable-active-high/ {
>   active_high = 1;
> }
> 
> /gpio-open-drain/ {
>   open_drain = 1;
> }
> 
> match($0, /gpio += <.* ([^ ]*)>/, ary) {
>   gpio = 1;
>   flags = ary[1];
>   if (flags == 0)
>   flags = "GPIO_ACTIVE_HIGH";
> }
> 
> /}/ {
>   if (found) {
>   if (gpio) {
>   print "\t" name ": active high " active_high " " flags 
> " open drain " open_drain;
>   if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
>   (!active_high && flags == "GPIO_ACTIVE_HIGH"))
>   print "WARNING: enable-active-high and flags do 
> not match"
>   } else {
>   if (active_high)
>   print "WARNING: active high without GPIO"
>   if (open_drain)
>   print "WARNING: open drain without GPIO"
>   }
>   }
> 
>   gpio = 0;
>   found = 0;
>   active_high = 0;
>   open_drain = 0;
>   flags = 0;
> }
> '
> --
> 
> All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
> are untested as I lack test hardware.
> 
> As there's no dependency between the patches touching different source files
> the appropriate maintainers could take their share of the patches in their
> tree. Alternatively I could send a single pull request after collecting all
> acks but that might be more complex.

Nice clean-up. For omaps, there's an earlier patch posted by
Javier Martinez Canillas  as "[PATCH] ARM: dts: Use
defined GPIO constants in flags cell for OMAP2+ boards". Can you guys do some
cross checking and let me know which combination I should appluy for omaps?

Regards,

Tony
--
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/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Tony Lindgren]

* Laurent Pinchart <laurent.pinch...@ideasonboard.com> [151012 15:26]:
> Hi Javier,
> 
> On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> > On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> > > * Laurent Pinchart <laurent.pinch...@ideasonboard.com> [151012 14:17]:
> > >> Hello,
> > >> 
> > >> While working on regulators, GPIOs and DT I noticed that many of our DT
> > >> source files incorrectly describe fixed regulators. The common error
> > >> patterns are
> > >> 
> > >> - Usage of the undefined (and never parsed) enable-active-low property
> > >> - Usage of the enable-active-high property without specifying an enable
> > >>   GPIO
> > >> - Typos in the enabl GPIO property name (gpios instead of gpio)
> > >> - Mismatch between the enable-active-high property (or the lack thereof)
> > >>   and the enable GPIO flags
> > >> 
> > >> This patch series fixes those issues in all the DT sources after locating
> > >> the errors using the following script.
> > >> 
> > >> -
> > >> !/bin/sh
> > >> 
> > >> echo $1
> > >> cat $1 | awk '
> > >> BEGIN {
> > >>  open_drain = 0;
> > >>  active_high = 0;
> > >>  gpio = 0;
> > >>  flags = 0;
> > >> }
> > >> 
> > >> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
> > >>  name = ary[1];
> > >> }
> > >> 
> > >> /compatible.*"regulator-fixed"/ {
> > >>  found = 1;
> > >> }
> > >> 
> > >> /enable-active-high/ {
> > >>  active_high = 1;
> > >> }
> > >> 
> > >> /gpio-open-drain/ {
> > >>  open_drain = 1;
> > >> }
> > >> 
> > >> match($0, /gpio += <.* ([^ ]*)>/, ary) {
> > >>  gpio = 1;
> > >>  flags = ary[1];
> > >>  if (flags == 0)
> > >>  flags = "GPIO_ACTIVE_HIGH";
> > >> }
> > >> 
> > >> /}/ {
> > >>  if (found) {
> > >>  if (gpio) {
> > >>  print "\t" name ": active high " active_high " " flags 
> > >> " open 
> drain "
> > >>  open_drain;
> > >>  if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
> > >>  (!active_high && flags == "GPIO_ACTIVE_HIGH"))
> > >>  print "WARNING: enable-active-high and flags do 
> > >> not 
> match"
> > >>  } else {
> > >>  if (active_high)
> > >>  print "WARNING: active high without GPIO"
> > >>  if (open_drain)
> > >>  print "WARNING: open drain without GPIO"
> > >>  }
> > >>  }
> > >>  
> > >>  gpio = 0;
> > >>  found = 0;
> > >>  active_high = 0;
> > >>  open_drain = 0;
> > >>  flags = 0;
> > >> }
> > >> '
> > >> -
> > >> 
> > >> All patches except for the ones touching omap3-beagle-xm and
> > >> omap3-overo-base are untested as I lack test hardware.
> > >> 
> > >> As there's no dependency between the patches touching different source
> > >> files the appropriate maintainers could take their share of the patches
> > >> in their tree. Alternatively I could send a single pull request after
> > >> collecting all acks but that might be more complex.
> > > 
> > > Nice clean-up. For omaps, there's an earlier patch posted by
> > > Javier Martinez Canillas <jav...@osg.samsung.com> as "[PATCH] ARM: dts:
> > > Use defined GPIO constants in flags cell for OMAP2+ boards". Can you guys
> > > do some cross checking and let me know which combination I should appluy
> > > for omaps?
> >
> > Since Laurent's changes for OMAP are part of a bigger series and my patch
> > was only for OMAP, probably makes sense for you to pick his patches and I
> > can re-spin mine on top of that.
> > 
> > BTW, I posted as a single patch since the changes were trivial but maybe
> > that made handling these conflicts harder and I should split the changes
> > instead, since I'll resend anyways.
> > 
> > What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
> > per board DTS?
> 
> My series will likely miss the next merge window as more discussion is 
> needed. 
> I'll thus respin the patches on top of yours, please proceed without caring 
> about this.

OK applying Javier's patch into omap-for-v4.4/dt then.

Regards,

Tony
--
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] arm:irqchip: IRQCHIP_DECLARE macro is now accessible

[Tony Lindgren]

* Krzysztof Kozlowski k.kozlow...@samsung.com [150707 16:49]:
 On 08.07.2015 05:02, Joel Porquet wrote:
  The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
  globally accessible.
  
  See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d
  (irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h).
  
  This patch adds inclusions of 'include/linux/irqchip.h' and replaces uses of
  macro OF_DECLARE_2 with IRQCHIP_DECLARE.
  
  Signed-off-by: Joel Porquet j...@porquet.org
  ---
   arch/arm/mach-exynos/suspend.c   | 3 ++-
   arch/arm/mach-imx/gpc.c  | 7 ++-
   arch/arm/mach-omap2/omap-wakeupgen.c | 7 ++-
   3 files changed, 6 insertions(+), 11 deletions(-)
  
 
 For Exynos:
 Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com

For omap changes:

Acked-by: Tony Lindgren t...@atomide.com
--
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] Show proper respect for Heinrich Hertz by using the correct unit for frequency

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [150511 06:23]:
 The SI unit of frequency is Hertz, named after Heinrich Hertz, and is
 given the symbol Hz to denote this.  hz is not the unit of frequency,
 and is in fact meaningless.
 
 Fix arch/arm to correctly use Hz, thereby acknowledging Heinrich Hertz
 contribution to the modern world.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Acked-by: Tony Lindgren t...@atomide.com
--
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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains

[Tony Lindgren]

* Marc Zyngier marc.zyng...@arm.com [150121 09:25]:
 On 21/01/15 16:30, Tony Lindgren wrote:
 
  I gave this a quick boot test on am437x-gp-evm and the
  interrupts look OK with the fix also applied:
  
  # cat /proc/interrupts 
  CPU0   
   16:657 WUGEN  68  gp_timer
   18:  0 WUGEN   9  l3-dbg-irq
   19:  0 WUGEN  10  l3-app-irq
   20:  5 WUGEN  12  edma
   22:  0 WUGEN  14  edma_error
   23: 96 WUGEN  72  OMAP UART0
   33:  0  44e07000.gpio   6  mmc0
  158: 52 WUGEN  70  44e0b000.i2c
  159:  0 WUGEN  71  4802a000.i2c
  160: 35 WUGEN  64  mmc0
  161:  0 WUGEN  40  4a10.ethernet
  162:   7739 WUGEN  41  4a10.ethernet
  163:   7608 WUGEN  42  4a10.ethernet
  164:  0 WUGEN  43  4a10.ethernet
  170:  0 WUGEN 100  gpmc
  180:  0 WUGEN   7  tps65218
  IPI0:  0  CPU wakeup interrupts
  IPI1:  0  Timer broadcast interrupts
  IPI2:  0  Rescheduling interrupts
  IPI3:  0  Function call interrupts
  IPI4:  0  Single function call interrupts
  IPI5:  0  CPU stop interrupts
  IPI6:  0  IRQ work interrupts
  IPI7:  0  completion interrupts
  Err:  0
 
 Interesting. No TWD timer on this one?

Good question, adding Felipe to cc. It eems to be there in
the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:

# cat /proc/interrupts 
CPU0   
 16:  0 WUGEN  67  gp_timer
 17:529   GIC  29  twd
 18:  0 WUGEN   9  l3-dbg-irq
 19:  0 WUGEN  10  l3-app-irq
 20:  5 WUGEN  12  edma
 22:  0 WUGEN  14  edma_error
 23:130 WUGEN  72  OMAP UART0
 34:  0  44e07000.gpio   6  mmc0
159: 52 WUGEN  70  44e0b000.i2c
160:  0 WUGEN  71  4802a000.i2c
161: 35 WUGEN  64  mmc0
162:  0 WUGEN  40  4a10.ethernet
163:   8033 WUGEN  41  4a10.ethernet
164:   7769 WUGEN  42  4a10.ethernet
165:  0 WUGEN  43  4a10.ethernet
171:  0 WUGEN 100  gpmc
181:  0 WUGEN   7  tps65218
IPI0:  0  CPU wakeup interrupts
IPI1:  0  Timer broadcast interrupts
IPI2:  0  Rescheduling interrupts
IPI3:  0  Function call interrupts
IPI4:  0  Single function call interrupts
IPI5:  0  CPU stop interrupts
IPI6:  0  IRQ work interrupts
IPI7:  0  completion interrupts
Err:  0

Hmm I wonder why we have the !is_smp() check in the TWD timer?

Regards,

Tony

8 ---
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -51,6 +51,14 @@
interrupt-parent = gic;
};
 
+   local-timer@48240600 {
+   compatible = arm,cortex-a9-twd-timer;
+   clocks = dpll_mpu_m2_ck;
+   reg = 0x48240600 0x20;
+   interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) | 
IRQ_TYPE_LEVEL_HIGH);
+   interrupt-parent = gic;
+   };
+
wakeupgen: interrupt-controller@48281000 {
compatible = ti,omap4-wugen-mpu;
interrupt-controller;
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -388,7 +388,7 @@ static void __init twd_local_timer_of_register(struct 
device_node *np)
 {
int err;
 
-   if (!is_smp() || !setup_max_cpus)
+   if (!setup_max_cpus)
return;
 
twd_ppi = irq_of_parse_and_map(np, 0);
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -237,7 +237,7 @@ DT_MACHINE_START(AM43_DT, Generic AM43 (Flattened Device 
Tree))
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap3_gptimer_timer_init,
+   .init_time  = omap4_local_timer_init,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
--
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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains

[Tony Lindgren]

* Marc Zyngier marc.zyng...@arm.com [150119 01:48]:
 OMAP4/5 has been (ab)using the gic_arch_extn to provide
 wakeup from suspend, and it makes a lot of sense to convert
 this code to use stacked domains instead.
 
 This patch does just this, updating the DT files to actually
 reflect what the HW provides.
 
 BIG FAT WARNING: because the DTs were so far lying by not
 exposing the WUGEN HW block, kernels with this patch applied
 won't have any suspend-resume facility when booted with old DTs,
 and old kernels with updated DTs won't even boot.
 
 On a platform with this patch applied, the system looks like
 this:
 
 root@bacon-fat:~# cat /proc/interrupts
 CPU0   CPU1
  16:  0  0 WUGEN  37  gp_timer
  19: 233799 155916   GIC  27  arch_timer
  23:  0  0 WUGEN   9  l3-dbg-irq
  24:  1  0 WUGEN  10  l3-app-irq
  27:282  0 WUGEN  13  omap-dma-engine
  44:  0  0  4ae1.gpio  13  DMA

You may want to update this part for the fix :)

I gave this a quick boot test on am437x-gp-evm and the
interrupts look OK with the fix also applied:

# cat /proc/interrupts 
CPU0   
 16:657 WUGEN  68  gp_timer
 18:  0 WUGEN   9  l3-dbg-irq
 19:  0 WUGEN  10  l3-app-irq
 20:  5 WUGEN  12  edma
 22:  0 WUGEN  14  edma_error
 23: 96 WUGEN  72  OMAP UART0
 33:  0  44e07000.gpio   6  mmc0
158: 52 WUGEN  70  44e0b000.i2c
159:  0 WUGEN  71  4802a000.i2c
160: 35 WUGEN  64  mmc0
161:  0 WUGEN  40  4a10.ethernet
162:   7739 WUGEN  41  4a10.ethernet
163:   7608 WUGEN  42  4a10.ethernet
164:  0 WUGEN  43  4a10.ethernet
170:  0 WUGEN 100  gpmc
180:  0 WUGEN   7  tps65218
IPI0:  0  CPU wakeup interrupts
IPI1:  0  Timer broadcast interrupts
IPI2:  0  Rescheduling interrupts
IPI3:  0  Function call interrupts
IPI4:  0  Single function call interrupts
IPI5:  0  CPU stop interrupts
IPI6:  0  IRQ work interrupts
IPI7:  0  completion interrupts
Err:  0

Also verified that suspend and resume to a serial console event
works on omap4430-sdp. So please feel free to add:

Acked-by: Tony Lindgren t...@atomide.com
--
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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains

[Tony Lindgren]

* santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]:
 On 1/21/2015 10:36 AM, Tony Lindgren wrote:
 * Marc Zyngier marc.zyng...@arm.com [150121 09:25]:
 On 21/01/15 16:30, Tony Lindgren wrote:
 
 I gave this a quick boot test on am437x-gp-evm and the
 interrupts look OK with the fix also applied:
 
 # cat /proc/interrupts
  CPU0
   16:657 WUGEN  68  gp_timer
   18:  0 WUGEN   9  l3-dbg-irq
   19:  0 WUGEN  10  l3-app-irq
   20:  5 WUGEN  12  edma
   22:  0 WUGEN  14  edma_error
   23: 96 WUGEN  72  OMAP UART0
   33:  0  44e07000.gpio   6  mmc0
 158: 52 WUGEN  70  44e0b000.i2c
 159:  0 WUGEN  71  4802a000.i2c
 160: 35 WUGEN  64  mmc0
 161:  0 WUGEN  40  4a10.ethernet
 162:   7739 WUGEN  41  4a10.ethernet
 163:   7608 WUGEN  42  4a10.ethernet
 164:  0 WUGEN  43  4a10.ethernet
 170:  0 WUGEN 100  gpmc
 180:  0 WUGEN   7  tps65218
 IPI0:  0  CPU wakeup interrupts
 IPI1:  0  Timer broadcast interrupts
 IPI2:  0  Rescheduling interrupts
 IPI3:  0  Function call interrupts
 IPI4:  0  Single function call interrupts
 IPI5:  0  CPU stop interrupts
 IPI6:  0  IRQ work interrupts
 IPI7:  0  completion interrupts
 Err:  0
 
 Interesting. No TWD timer on this one?
 
 Good question, adding Felipe to cc. It eems to be there in
 the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
 MPU_PRV_TIMERS. Also seems to actually work with the
 attached patch:
 
 TWD is useless on this machine since single core and TWD
 as know die in low power states. All the broadcast stuff
 is for SMP machines.

Hmm it seems we should still use TWD during runtime and
swich over to the gptimer for idle states for wake-up
events.

Regards,

Tony
--
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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains

[Tony Lindgren]

* santosh shilimkar santosh.shilim...@oracle.com [150121 13:31]:
 On 1/21/2015 12:43 PM, Tony Lindgren wrote:
 * santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]:
 
 TWD is useless on this machine since single core and TWD
 as know die in low power states. All the broadcast stuff
 is for SMP machines.
 
 Hmm it seems we should still use TWD during runtime and
 swich over to the gptimer for idle states for wake-up
 events.
 
 Well timer wheel code don't support it so if you are serious,
 some one needs to do that. For me, it is not worth at all.
 You will have more to loose than gain with these time switching
 schemes since you have to keep 2 times alive, do switching, loose
 the idle time.
 
 All of that is to save few CPU cycles since TWD is closer
 compared to other SOC timer.
 
 Anyways I will let you fight it out but IIRC, I had a
 discussion a while back with tglx in one of the conference
 and the conclusion was it not worth doing.
 Rather TWD hardware on SOC should be made wakeup capable
 and then everything is good.
 
 Till you have support, using TWD on AM43XX will break CPUIDLE.
 Not sure if it is supported or some one cares about it. Just
 keep that aspect in mind.

Yes sure I'm aware of this. It should be easy to profile the
speed gain to see if it would make much of a difference
before starting to tinker with that.

The way I think it's possible to do would be to copy the TWD
timer value to a wake-up capable gptimer before hitting any
deeper idle state. Of course some aux timer support might be
still needed :)

Regards,

Tony
--
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 v3 13/21] ARM: omap: convert wakeupgen to stacked domains

[Tony Lindgren]

* Marc Zyngier marc.zyng...@arm.com [150115 09:31]:
 On 15/01/15 17:04, Tony Lindgren wrote:
  * Marc Zyngier marc.zyng...@arm.com [150115 06:53]:
  On Thu, Jan 15 2015 at  2:40:16 pm GMT, Nishanth Menon n...@ti.com wrote:
  On 14:28-20150115, Marc Zyngier wrote:
  Assuming the workaround I posted earlier works, the OMAP/DRA7 part of
  this series is going to require some rework too (I need to know where
  these legacy interrupts are attached: crossbar, WUGEN, or GIC?).
 
  crossbar will never work with legacy static interrupts anyways - since
  there was never a static interrupt possible - I believe we had removed
  all the legacy hardcoded interrupt definitions for DRA7. ideally, they
  should all be dt only now.
 
  Yes, I guessed as much after looking at the DRA7XX hwmod.
 
  So only OMAP4/5 is b0rken at the moment. I can probably work around it
  as I did in this example patch, just by changing the compatible strings
  for the xlate callback. Very ugly.
  
  For the -rc, it seems the wakeupen still needs a fix as based on grepping
  for OMAP44XX_IRQ_GIC_START. Got any great ideas for that?
 
 I think this one is fine. It computes the SPI number based on the hwirq
 coming from the GIC. That direction is completely unaffected by the
 linear domain stuff. It is only when you try to use a hardware IRQ as a
 Linux IRQ that you run into trouble.

Yes OK that makes sense.

Thanks,

Tony
--
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 v3 13/21] ARM: omap: convert wakeupgen to stacked domains

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [150115 10:04]:
 * Marc Zyngier marc.zyng...@arm.com [150115 09:31]:
  On 15/01/15 17:04, Tony Lindgren wrote:
   * Marc Zyngier marc.zyng...@arm.com [150115 06:53]:
   On Thu, Jan 15 2015 at  2:40:16 pm GMT, Nishanth Menon n...@ti.com 
   wrote:
   On 14:28-20150115, Marc Zyngier wrote:
   Assuming the workaround I posted earlier works, the OMAP/DRA7 part of
   this series is going to require some rework too (I need to know where
   these legacy interrupts are attached: crossbar, WUGEN, or GIC?).
  
   crossbar will never work with legacy static interrupts anyways - since
   there was never a static interrupt possible - I believe we had removed
   all the legacy hardcoded interrupt definitions for DRA7. ideally, they
   should all be dt only now.
  
   Yes, I guessed as much after looking at the DRA7XX hwmod.
  
   So only OMAP4/5 is b0rken at the moment. I can probably work around it
   as I did in this example patch, just by changing the compatible strings
   for the xlate callback. Very ugly.
   
   For the -rc, it seems the wakeupen still needs a fix as based on grepping
   for OMAP44XX_IRQ_GIC_START. Got any great ideas for that?
  
  I think this one is fine. It computes the SPI number based on the hwirq
  coming from the GIC. That direction is completely unaffected by the
  linear domain stuff. It is only when you try to use a hardware IRQ as a
  Linux IRQ that you run into trouble.
 
 Yes OK that makes sense.

And suspend and resume seem to work with your fix.

FYI, to test suspend and resume with wakeups from the serial console,
the uart wakeup events need to be enabled under sys:

#!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2/dev/null)
for uart in $uarts; do
echo enabled  $uart/wakeup 21
done

And after that suspending with echo mem  /sys/power/state should wake
to a serial interrupt.

Regards,

Tony
--
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 v3 13/21] ARM: omap: convert wakeupgen to stacked domains

[Tony Lindgren]

* Marc Zyngier marc.zyng...@arm.com [150112 10:30]:
 OMAP4/5 has been (ab)using the gic_arch_extn to provide
 wakeup from suspend, and it makes a lot of sense to convert
 this code to use stacked domains instead.
 
 This patch does just this, updating the DT files to actually
 reflect what the HW provides.
 
 BIG FAT WARNING: because the DTs were so far lying by not
 exposing the WUGEN HW block, kernels with this patch applied
 won't have any suspend-resume facility when booted with old DTs,
 and old kernels with updated DTs won't even boot.
 
 On a platform with this patch applied, the system looks like
 this:
 
 root@bacon-fat:~# cat /proc/interrupts
 CPU0   CPU1
  16:  0  0 WUGEN  37  gp_timer
  19: 233799 155916   GIC  27  arch_timer
  23:  0  0 WUGEN   9  l3-dbg-irq
  24:  1  0 WUGEN  10  l3-app-irq
  27:282  0 WUGEN  13  omap-dma-engine
  44:  0  0  4ae1.gpio  13  DMA

FYI, the legacy irq numbers are now all wrong since commit
9a1091ef0017 (irqchip: gic: Support hierarchy irq domain.).

Started a separate thread Regression with legacy IRQ numbers
caused by 9a1091ef0017 on it, will give these a try once
that's sorted out.

Regards,

Tony
--
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 v11 2/9] ARM: l2c: use l2c_write_sec() for restoring latency and filter regs

[Tony Lindgren]

* Marek Szyprowski m.szyprow...@samsung.com [150105 04:22]:
 All four register for latency and filter settings cannot be written in
 non-secure mode and they should go through l2c_write_sec(). More on this
 can be found in CoreLink Level 2 Cache Controller L2C-310 Technical
 Reference Manual, 3.2. Register summary, table 3.1. This have been checked
 the TRM for r3p3, but it should be uniform for all revisions.
 
 Reported-by: Nishanth Menon n...@ti.com
 Suggested-by: Tomasz Figa tomasz.f...@gmail.com
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/mm/cache-l2x0.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)
 
 diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
 index 5e65ca8dea62..0aeeaa95c42d 100644
 --- a/arch/arm/mm/cache-l2x0.c
 +++ b/arch/arm/mm/cache-l2x0.c
 @@ -623,14 +623,14 @@ static void l2c310_resume(void)
   unsigned revision;
  
   /* restore pl310 setup */
 - writel_relaxed(l2x0_saved_regs.tag_latency,
 -base + L310_TAG_LATENCY_CTRL);
 - writel_relaxed(l2x0_saved_regs.data_latency,
 -base + L310_DATA_LATENCY_CTRL);
 - writel_relaxed(l2x0_saved_regs.filter_end,
 -base + L310_ADDR_FILTER_END);
 - writel_relaxed(l2x0_saved_regs.filter_start,
 -base + L310_ADDR_FILTER_START);
 + l2c_write_sec(l2x0_saved_regs.tag_latency, base,
 +   L310_TAG_LATENCY_CTRL);
 + l2c_write_sec(l2x0_saved_regs.data_latency, base,
 +   L310_DATA_LATENCY_CTRL);
 + l2c_write_sec(l2x0_saved_regs.filter_end, base,
 +   L310_ADDR_FILTER_END);
 + l2c_write_sec(l2x0_saved_regs.filter_start, base,
 +   L310_ADDR_FILTER_START);
  
   revision = readl_relaxed(base + L2X0_CACHE_ID) 
   L2X0_CACHE_ID_RTL_MASK;
 -- 
 1.9.2
 
--
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 v11 3/9] ARM: l2c: Refactor the driver to use commit-like interface

[Tony Lindgren]

* Marek Szyprowski m.szyprow...@samsung.com [150105 04:22]:
 From: Tomasz Figa t.f...@samsung.com
 
 Certain implementations of secure hypervisors (namely the one found on
 Samsung Exynos-based boards) do not provide access to individual L2C
 registers. This makes the .write_sec()-based interface insufficient and
 provoking ugly hacks.
 
 This patch is first step to make the driver not rely on availability of
 writes to individual registers. This is achieved by refactoring the
 driver to use a commit-like operation scheme: all register values are
 prepared first and stored in an instance of l2x0_regs struct and then a
 single callback is responsible to flush those values to the hardware.
 
 Signed-off-by: Tomasz Figa t.f...@samsung.com
 [mszyprow: rebased onto 'ARM: l2c: use l2c_write_sec() for restoring
  latency and filter regs' patch]
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

This version seems to boot just fine on am437x here:

Acked-by: Tony Lindgren t...@atomide.com
--
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 v11 4/9] ARM: l2c: Add interface to ask hypervisor to configure L2C

[Tony Lindgren]

* Marek Szyprowski m.szyprow...@samsung.com [150105 04:22]:
 From: Tomasz Figa t.f...@samsung.com
 
 Because certain secure hypervisor do not allow writes to individual L2C
 registers, but rather expect set of parameters to be passed as argument
 to secure monitor calls, there is a need to provide an interface for the
 L2C driver to ask the firmware to configure the hardware according to
 specified parameters. This patch adds such.
 
 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/include/asm/outercache.h | 3 +++
  arch/arm/mm/cache-l2x0.c  | 6 ++
  2 files changed, 9 insertions(+)
 
 diff --git a/arch/arm/include/asm/outercache.h 
 b/arch/arm/include/asm/outercache.h
 index 891a56b35bcf..563b92fc2f41 100644
 --- a/arch/arm/include/asm/outercache.h
 +++ b/arch/arm/include/asm/outercache.h
 @@ -23,6 +23,8 @@
  
  #include linux/types.h
  
 +struct l2x0_regs;
 +
  struct outer_cache_fns {
   void (*inv_range)(unsigned long, unsigned long);
   void (*clean_range)(unsigned long, unsigned long);
 @@ -36,6 +38,7 @@ struct outer_cache_fns {
  
   /* This is an ARM L2C thing */
   void (*write_sec)(unsigned long, unsigned);
 + void (*configure)(const struct l2x0_regs *);
  };
  
  extern struct outer_cache_fns outer_cache;
 diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
 index f9013320c8ce..dcde6086a228 100644
 --- a/arch/arm/mm/cache-l2x0.c
 +++ b/arch/arm/mm/cache-l2x0.c
 @@ -110,6 +110,11 @@ static inline void l2c_unlock(void __iomem *base, 
 unsigned num)
  
  static void l2c_configure(void __iomem *base)
  {
 + if (outer_cache.configure) {
 + outer_cache.configure(l2x0_saved_regs);
 + return;
 + }
 +
   if (l2x0_data-configure)
   l2x0_data-configure(base);
  
 @@ -910,6 +915,7 @@ static int __init __l2c_init(const struct l2c_init_data 
 *data,
  
   fns = data-outer_cache;
   fns.write_sec = outer_cache.write_sec;
 + fns.configure = outer_cache.configure;
   if (data-fixup)
   data-fixup(l2x0_base, cache_id, fns);
  
 -- 
 1.9.2
 
--
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 v11 5/9] ARM: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL

[Tony Lindgren]

* Marek Szyprowski m.szyprow...@samsung.com [150105 04:22]:
 From: Tomasz Figa t.f...@samsung.com
 
 Certain platforms (i.e. Exynos) might need to set .write_sec callback
 from firmware initialization which is happenning in .init_early callback
 of machine descriptor. However current code will overwrite the pointer
 with whatever is present in machine descriptor, even though it can be
 already set earlier. This patch fixes this by making the assignment
 conditional, depending on whether current .write_sec callback is NULL.
 
 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/kernel/irq.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
 index ad857bada96c..350f188c92d2 100644
 --- a/arch/arm/kernel/irq.c
 +++ b/arch/arm/kernel/irq.c
 @@ -109,7 +109,8 @@ void __init init_IRQ(void)
  
   if (IS_ENABLED(CONFIG_OF)  IS_ENABLED(CONFIG_CACHE_L2X0) 
   (machine_desc-l2c_aux_mask || machine_desc-l2c_aux_val)) {
 - outer_cache.write_sec = machine_desc-l2c_write_sec;
 + if (!outer_cache.write_sec)
 + outer_cache.write_sec = machine_desc-l2c_write_sec;
   ret = l2x0_of_init(machine_desc-l2c_aux_val,
  machine_desc-l2c_aux_mask);
   if (ret)
 -- 
 1.9.2
 
--
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 v11 6/9] ARM: l2c: Add support for overriding prefetch settings

[Tony Lindgren]

* Marek Szyprowski m.szyprow...@samsung.com [150105 04:22]:
 From: Tomasz Figa t.f...@samsung.com
 
 Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
 settings configured in registers leading to crashes if L2C is enabled
 without overriding them. This patch introduces bindings to enable
 prefetch settings to be specified from DT and necessary support in the
 driver.
 
 Signed-off-by: Tomasz Figa t.f...@samsung.com
 [mszyprow: rebased onto v3.18-rc1, added error message when prefetch related
  dt property has been provided without any value]
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

Acked-by: Tony Lindgren t...@atomide.com
--
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 v11 1/9] ARM: OMAP2+: use common l2cache initialization code

[Tony Lindgren]

* Marek Szyprowski m.szyprow...@samsung.com [150105 04:22]:
 This patch implements generic DT L2C initialisation (the one from
 init_IRQ in arch/arm/kernel/irq.c) for Omap4 and AM43 platforms and
 kills the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

Seems to work just fine for me:

Acked-by: Tony Lindgren t...@atomide.com
--
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 v10 2/8] ARM: l2c: Refactor the driver to use commit-like interface

[Tony Lindgren]

* Marek Szyprowski m.szyprow...@samsung.com [141223 02:51]:
 From: Tomasz Figa t.f...@samsung.com
 
 Certain implementations of secure hypervisors (namely the one found on
 Samsung Exynos-based boards) do not provide access to individual L2C
 registers. This makes the .write_sec()-based interface insufficient and
 provoking ugly hacks.
 
 This patch is first step to make the driver not rely on availability of
 writes to individual registers. This is achieved by refactoring the
 driver to use a commit-like operation scheme: all register values are
 prepared first and stored in an instance of l2x0_regs struct and then a
 single callback is responsible to flush those values to the hardware.

The first patch of the series applied things boot with no problem.
But after applying this one I get the following on am437x:

Unhandled fault: imprecise external abort (0xc06) at 0xb6f33884

Probably the same issue Nishanth mentioned.

Regards,

Tony
--
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: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [141222 09:06]:
 On Thu, Dec 11, 2014 at 11:42:48AM +0100, Marek Szyprowski wrote:
  On 2014-12-11 10:29, Russell King - ARM Linux wrote:
  On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote:
  I assume that now it won't be possible to get l2c patches back to -next,
  so I will resend them (again...) with the omap related fix.
  What, you mean you don't know the fundamental rules of kernel development?
  
  No one should ever dump any new code into linux-next during a merge
  window which is not a fix for a regression or a bug fix, period.
  
  Linus has in the past taken a snapshot of linux-next at the beginning
  of a merge window, and then threatened to refuse to merge anything that
  wasn't in his local snapshot, or which doesn't qualify as the above.
  
  So no, it won't be possible, because I play by the community rules when
  it comes to what gets merged and at what time in the cycle.
  
  I know the rules. It was just my whining, that it is yet another release
  cycle
  that got missed. It is really disappointing, that those patches have been
  floating for months and noone found issues related to different order of
  initialization. It took way to long to get them scheduled for testing in
  -next.
 
 Right, so - we're now at -rc1, and we should see about queuing this up
 sooner rather than later - in its fixed form.  From what I can see,
 there's been little progress on the OMAP problem.
 
 Nishanth - can we push OMAP over to using the generic DT L2C
 initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and
 kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ?
 
 From what I can see, in the DT case, the only thing which is used
 there is the ioremap() to provide omap4_get_l2cache_base() with
 something to return.  Everything else - the initialisation of the
 l2c_write_sec pointer, and the aux mask and values - can be specified
 via the machine_desc struct.
 
 That only leaves the non-DT stuff to worry about this, and from what I
 understand, that's going to be removed soon.  If we're going to keep
 the non-DT stuff, we should implement a new machine_desc hook for it
 instead of hijacking one of the existing callbacks.

For omap4 and later we've been DT only for about 1.5 years now so
that should not be an issue here.

Regards,

Tony
--
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 51/75] ARM: l2c: remove platforms/SoCs setting early BRESP

[Tony Lindgren]

* Russell King rmk+ker...@arm.linux.org.uk [140328 08:22]:
 Since we now automatically enable early BRESP in core L2C-310 code when
 we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
 explicitly.  Instead, they should seek to preserve the value of bit 30
 in the auxiliary control register.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Acked-by: Tony Lindgren t...@atomide.com
--
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 49/75] ARM: l2c: fix register naming

[Tony Lindgren]

* Russell King rmk+ker...@arm.linux.org.uk [140328 08:22]:
 We have a mixture of different devices with different register layouts,
 but we group all the bits together in an opaque mess.  Split them out
 into those which are L2C-310 specific and ones which refer to earlier
 devices.  Provide full auxiliary control register definitions.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Acked-by: Tony Lindgren t...@atomide.com

 --- a/arch/arm/mach-omap2/omap4-common.c
 +++ b/arch/arm/mach-omap2/omap4-common.c
 @@ -212,15 +212,15 @@ static int __init omap_l2_cache_init(void)
   return -ENOMEM;
  
   /* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
 - aux_ctrl = (1  L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT) |
 - (0x1  25) |
 - (0x1  L2X0_AUX_CTRL_NS_LOCKDOWN_SHIFT) |
 - (0x1  L2X0_AUX_CTRL_NS_INT_CTRL_SHIFT)) |
 - (0x3  L2X0_AUX_CTRL_WAY_SIZE_SHIFT) |
 - (1  L2X0_AUX_CTRL_SHARE_OVERRIDE_SHIFT) |
 - (1  L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT) |
 - (1  L2X0_AUX_CTRL_INSTR_PREFETCH_SHIFT) |
 - (1  L2X0_AUX_CTRL_EARLY_BRESP_SHIFT);
 + aux_ctrl = L310_AUX_CTRL_ASSOCIATIVITY_16 |
 +L310_AUX_CTRL_CACHE_REPLACE_RR |
 +L310_AUX_CTRL_NS_LOCKDOWN |
 +L310_AUX_CTRL_NS_INT_CTRL |
 +L2C_AUX_CTRL_WAY_SIZE(3) |
 +L2C_AUX_CTRL_SHARED_OVERRIDE |
 +L310_AUX_CTRL_DATA_PREFETCH |
 +L310_AUX_CTRL_INSTR_PREFETCH |
 +L310_AUX_CTRL_EARLY_BRESP;

I guess eventually we can set up some common configuration mask
define for these kind of things?

Regards,

Tony
--
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 49/75] ARM: l2c: fix register naming

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [140328 14:06]:
 On Fri, Mar 28, 2014 at 09:00:48AM -0700, Tony Lindgren wrote:
  * Russell King rmk+ker...@arm.linux.org.uk [140328 08:22]:
   We have a mixture of different devices with different register layouts,
   but we group all the bits together in an opaque mess.  Split them out
   into those which are L2C-310 specific and ones which refer to earlier
   devices.  Provide full auxiliary control register definitions.
   
   Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
  
  Acked-by: Tony Lindgren t...@atomide.com
  
   --- a/arch/arm/mach-omap2/omap4-common.c
   +++ b/arch/arm/mach-omap2/omap4-common.c
   @@ -212,15 +212,15 @@ static int __init omap_l2_cache_init(void)
 return -ENOMEM;

 /* 16-way associativity, parity disabled, way size - 64KB (es2.0 +) */
   - aux_ctrl = (1  L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT) |
   - (0x1  25) |
   - (0x1  L2X0_AUX_CTRL_NS_LOCKDOWN_SHIFT) |
   - (0x1  L2X0_AUX_CTRL_NS_INT_CTRL_SHIFT)) |
   - (0x3  L2X0_AUX_CTRL_WAY_SIZE_SHIFT) |
   - (1  L2X0_AUX_CTRL_SHARE_OVERRIDE_SHIFT) |
   - (1  L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT) |
   - (1  L2X0_AUX_CTRL_INSTR_PREFETCH_SHIFT) |
   - (1  L2X0_AUX_CTRL_EARLY_BRESP_SHIFT);
   + aux_ctrl = L310_AUX_CTRL_ASSOCIATIVITY_16 |
   +L310_AUX_CTRL_CACHE_REPLACE_RR |
   +L310_AUX_CTRL_NS_LOCKDOWN |
   +L310_AUX_CTRL_NS_INT_CTRL |
   +L2C_AUX_CTRL_WAY_SIZE(3) |
   +L2C_AUX_CTRL_SHARED_OVERRIDE |
   +L310_AUX_CTRL_DATA_PREFETCH |
   +L310_AUX_CTRL_INSTR_PREFETCH |
   +L310_AUX_CTRL_EARLY_BRESP;
  
  I guess eventually we can set up some common configuration mask
  define for these kind of things?
 
 The idea is that eventually platforms should just specify no changes to
 the auxctl configuration.  You will notice later patches remove a number
 of the above flags.

OK thanks great!

Tony
--
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 4/5] arm: omap3: twl: use the new lookup method with usb phy

[Tony Lindgren]

* Heikki Krogerus heikki.kroge...@linux.intel.com [131209 07:10]:
 Provide a complete association for the phy and it's user
 (musb) with the new phy_lookup_table.

This seems safe to queue via the USB list:

Acked-by: Tony Lindgren t...@atomide.com
 
 Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
 ---
  arch/arm/mach-omap2/twl-common.c | 15 ++-
  1 file changed, 6 insertions(+), 9 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/twl-common.c 
 b/arch/arm/mach-omap2/twl-common.c
 index b0d54da..972430b 100644
 --- a/arch/arm/mach-omap2/twl-common.c
 +++ b/arch/arm/mach-omap2/twl-common.c
 @@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
  }
  
  #if defined(CONFIG_ARCH_OMAP3)
 -struct phy_consumer consumers[] = {
 - PHY_CONSUMER(musb-hdrc.0, usb),
 -};
 -
 -struct phy_init_data init_data = {
 - .consumers = consumers,
 - .num_consumers = ARRAY_SIZE(consumers),
 +static struct phy_lookup_table twl4030_usb_lookup = {
 + .dev_id = musb-hdrc.0,
 + .table = PHY_LOOKUP(phy-twl4030_usb.0, NULL),
  };
  
  static struct twl4030_usb_data omap3_usb_pdata = {
   .usb_mode   = T2_USB_MODE_ULPI,
 - .init_data  = init_data,
  };
  
  static int omap3_batt_table[] = {
 @@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct 
 twl4030_platform_data *pmic_data,
   }
  
   /* Common platform data configurations */
 - if (pdata_flags  TWL_COMMON_PDATA_USB  !pmic_data-usb)
 + if (pdata_flags  TWL_COMMON_PDATA_USB  !pmic_data-usb) {
 + phy_add_lookup_table(twl4030_usb_lookup);
   pmic_data-usb = omap3_usb_pdata;
 + }
  
   if (pdata_flags  TWL_COMMON_PDATA_BCI  !pmic_data-bci)
   pmic_data-bci = omap3_bci_pdata;
 -- 
 1.8.5.1
 
--
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 04/15] ARM: OMAP: USB: Add phy binding information

[Tony Lindgren]

* Kishon Vijay Abraham I kis...@ti.com [130717 23:53]:
 In order for controllers to get PHY in case of non dt boot, the phy
 binding information (phy device name) should be added in the platform
 data of the controller.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
 Acked-by: Felipe Balbi ba...@ti.com
 ---
  arch/arm/mach-omap2/usb-musb.c |3 +++
  include/linux/usb/musb.h   |3 +++
  2 files changed, 6 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
 index 8c4de27..6aa7cbf 100644
 --- a/arch/arm/mach-omap2/usb-musb.c
 +++ b/arch/arm/mach-omap2/usb-musb.c
 @@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data 
 *musb_board_data)
   musb_plat.mode = board_data-mode;
   musb_plat.extvbus = board_data-extvbus;
  
 + if (cpu_is_omap34xx())
 + musb_plat.phy_label = twl4030;
 +
   if (soc_is_am35xx()) {
   oh_name = am35x_otg_hs;
   name = musb-am35x;

I don't think there's a USB PHY on non-twl4030 chips, so this should
be OK:

Acked-by: Tony Lindgren t...@atomide.com


 diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
 index 053c268..596f8c8 100644
 --- a/include/linux/usb/musb.h
 +++ b/include/linux/usb/musb.h
 @@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
   /* for clk_get() */
   const char  *clock;
  
 + /* phy label */
 + const char  *phy_label;
 +
   /* (HOST or OTG) switch VBUS on/off */
   int (*set_vbus)(struct device *dev, int is_on);
  
 -- 
 1.7.10.4
 
--
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 05/15] ARM: dts: omap: update usb_otg_hs data

[Tony Lindgren]

* Kishon Vijay Abraham I kis...@ti.com [130717 23:53]:
 Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
 binding in order for the driver to use the new generic PHY framework.
 Also updated the Documentation to include the binding information.
 The PHY binding information can be found at
 Documentation/devicetree/bindings/phy/phy-bindings.txt
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 Acked-by: Felipe Balbi ba...@ti.com
 Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com

In general the .dts changes should be separate to avoid pointless
merge conflicts. But sounds like things will stop working for
USB unless we do it like this so:

Acked-by: Tony Lindgren t...@atomide.com


 ---
  Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
  Documentation/devicetree/bindings/usb/usb-phy.txt  |6 ++
  arch/arm/boot/dts/omap3-beagle-xm.dts  |2 ++
  arch/arm/boot/dts/omap3-evm.dts|2 ++
  arch/arm/boot/dts/omap3-overo.dtsi |2 ++
  arch/arm/boot/dts/omap4.dtsi   |3 +++
  arch/arm/boot/dts/twl4030.dtsi |1 +
  7 files changed, 21 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
 b/Documentation/devicetree/bindings/usb/omap-usb.txt
 index 57e71f6..825790d 100644
 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
 +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
 @@ -19,6 +19,9 @@ OMAP MUSB GLUE
   - power : Should be 50. This signifies the controller can supply up to
 100mA when operating in host mode.
   - usb-phy : the phandle for the PHY device
 + - phys : the phandle for the PHY device (used by generic PHY framework)
 + - phy-names : the names of the PHY corresponding to the PHYs present in the
 +   *phy* phandle.
  
  Optional properties:
   - ctrl-module : phandle of the control module this glue uses to write to
 @@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
   num-eps = 16;
   ram-bits = 12;
   ctrl-module = omap_control_usb;
 + phys = usb2_phy;
 + phy-names = usb2-phy;
  };
  
  Board specific device node entry
 diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
 b/Documentation/devicetree/bindings/usb/usb-phy.txt
 index 61496f5..c0245c8 100644
 --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
 +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
 @@ -5,6 +5,8 @@ OMAP USB2 PHY
  Required properties:
   - compatible: Should be ti,omap-usb2
   - reg : Address and length of the register set for the device.
 + - #phy-cells: determine the number of cells that should be given in the
 +   phandle while referencing this phy.
  
  Optional properties:
   - ctrl-module : phandle of the control module used by PHY driver to power on
 @@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
   compatible = ti,omap-usb2;
   reg = 0x4a0ad080 0x58;
   ctrl-module = omap_control_usb;
 + #phy-cells = 0;
  };
  
  OMAP USB3 PHY
 @@ -25,6 +28,8 @@ Required properties:
   - reg : Address and length of the register set for the device.
   - reg-names: The names of the register addresses corresponding to the 
 registers
 filled in reg.
 + - #phy-cells: determine the number of cells that should be given in the
 +   phandle while referencing this phy.
  
  Optional properties:
   - ctrl-module : phandle of the control module used by PHY driver to power on
 @@ -39,4 +44,5 @@ usb3phy@4a084400 {
 0x4a084c00 0x40;
   reg-names = phy_rx, phy_tx, pll_ctrl;
   ctrl-module = omap_control_usb;
 + #phy-cells = 0;
  };
 diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm.dts
 index afdb164..533b2da 100644
 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
 +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
 @@ -144,6 +144,8 @@
  usb_otg_hs {
   interface-type = 0;
   usb-phy = usb2_phy;
 + phys = usb2_phy;
 + phy-names = usb2-phy;
   mode = 3;
   power = 50;
  };
 diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
 index 7d4329d..4134dd0 100644
 --- a/arch/arm/boot/dts/omap3-evm.dts
 +++ b/arch/arm/boot/dts/omap3-evm.dts
 @@ -70,6 +70,8 @@
  usb_otg_hs {
   interface-type = 0;
   usb-phy = usb2_phy;
 + phys = usb2_phy;
 + phy-names = usb2-phy;
   mode = 3;
   power = 50;
  };
 diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
 b/arch/arm/boot/dts/omap3-overo.dtsi
 index 8f1abec..a461d2f 100644
 --- a/arch/arm/boot/dts/omap3-overo.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo.dtsi
 @@ -76,6 +76,8 @@
  usb_otg_hs {
   interface-type = 0;
   usb-phy = usb2_phy;
 + phys = usb2_phy;
 + phy-names = usb2-phy;
   mode = 3;
   power = 50;
  };
 diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
 index 22d9f2b..1e8e2fe 100644
 --- a/arch/arm/boot/dts/omap4.dtsi
 +++ b/arch/arm/boot/dts/omap4.dtsi
 @@ -520,6 +520,7

Re: [PATCH] ARM: OMAP: remove unused variable

[Tony Lindgren]

* Arnd Bergmann a...@arndb.de [130423 14:28]:
 ARM: OMAP: remove unused variable
 
 Commit 0583fe478a7 ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
 has left the omap5_realtime_timer_init() function with a stale variable and
 broken whitespace. This fixes both.
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 ---
 I've applied this patch on top of the timer cleanup series

OK thanks.

Tony
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index 7dd6453..686e498 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -618,12 +618,10 @@ OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, 
 ti,timer-alwon,
   2, OMAP4_MPU_SOURCE);
  void __init omap5_realtime_timer_init(void)
  {
 - int err;
 -
   omap5_sync32k_timer_init();
   realtime_counter_init();
  
 -clocksource_of_init();
 + clocksource_of_init();
  }
  #endif /* CONFIG_SOC_OMAP5 */
  
--
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/23] RFC: exynos multiplatform support

[Tony Lindgren]

* Arnd Bergmann a...@arndb.de [130305 09:51]:
 Hi everyone,
 
 Although I'm not present at the Linaro Connect hacking
 sessions, I am participating remotely and have tried
 hacking on multiplatform support for Exynos. This patch
 set is far from complete, but I think the patches
 can be useful anyway.
 
 The series gets increasingly fishy towards the end,
 and we should probably not apply any of the last nine
 patches as-is, nor do I expect everything to work, since
 I have not tested them at all.
 
 With this patch set, we can build mach-exynos as part
 of a multiplatform kernel, with the following caveats:
 
 * Only DT based boards are supported
 * Moving to common-clk breaks things including cpufreq
   and others. Thomas is working on a patch for this
 * We disable the gpio implementation, which also breaks
   stuff, but Thomas has a patch already
 * Using the generic DMA engine API in SPI and ASoC
   means they no longer work on S3C
 * I did not like the solution for the UART driver, but
   could also not think of a better one.
 * The FB_S3C, S3C2410_WATCHDOG and S3C_ADC drivers
   are left as an exercise to the reader, they are
   currently disabled with multiplatform
 * sparsemem support is not available on multiplatform

For booting, you might want to add fixing up of the initcalls
to your checklist too as that can easily cause surprises to
other SoCs.

Regards,

Tony
--
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 032/493] arm: remove use of __devexit_p

[Tony Lindgren]

* Bill Pemberton wf...@virginia.edu [121119 10:29]:
 CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
 needed.

For the arch/arm/*omap*/* touching patches:

Acked-by: Tony Lindgren t...@atomide.com
--
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 01/16] ARM: dts: exynos4210: Replace legacy GPIO bank nodes with pinctrl bank nodes

[Tony Lindgren]

* Stephen Warren swar...@wwwdotorg.org [121010 09:36]:
 On 10/10/2012 01:26 AM, Linus Walleij wrote:
  On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa t.f...@samsung.com wrote:
  
  Seuqential patches from this series introduce SoC-specific data parsing
  from device tree.
 
  This patch removes legacy GPIO bank nodes from exynos4210.dtsi and
  replaces them with nodes and properties required for these patches.
  
  So to be clear:
  
  +   pinctrl-bank-types {
  +   bank_off: bank-off {
  +   samsung,reg-names = func, dat, pud,
  +   drv, conpdn, pudpdn;
  +   samsung,reg-params = 0x00 4, 0x04 1, 0x08 2,
  +   0x0C 2, 0x10 2, 0x14 
  2;
  +   };
  
  This is starting to look like a firmware language, I have mixed
  feelings about this. Shall this be read:
  
  Poke 4 into 0x00, poke 1 into 0x04, poke 2 into 0x08 etc?
  
  We really need to discuss this, Grant has already NACK:ed
  such approaches once.
 
 Well, I don't think he NACK'd Tony Lindgren's generic pinctrl driver,
 which is doing this exact same thing. I did raise the same point about
 Tony's driver when he posted it, but nobody seemed inclined to NACK it
 based on that at the time, IIRC...

To summarize, using reg value pairs in DT makes sense if the amount
of data is huge. Otherwise we'll be describing indidual hardware bits
as properties in DT, or have to have huge amounts of static data in
the kernel.

Where it does not make sense is if there's a sequence of reads
and writes with test loops in between.. But that's does not look
to be the case here.

The reg value pairs will be readable when the DT preprocessing is
available, and that allows the values to be orred together while
DT properties don't. The alternative is to describe hardware register
bits as DT properties, which is very bloated.

But considering all this.. Are the samsung,reg-names really needed
by the kernel?

The pinctrl named modes actually are more generic from the pinctrl
client driver point of view as you can set up multiple states for
runtime PM.
 
 BTW, the idea here is IIRC to create a generic Samsung pinctrl driver
 that works across N different Samsung SoCs, each with different register
 layout, without having to encode the register layout into tables in the
 kernel.
 
  If you're still going to do this, it is mandatory
  to NOT use magic hex numbers anymore, because Stephen has
  merged preprocessor support to the DTC compiler so you
  can use #defined macros.
  
  See commit:
  cd296721a9645f9f28800a072490fa15458d1fb7
 
 That feature isn't enabled yet. While dtc has been modified to be able
 to accept input that's been generated/processed by cpp, there is still
 ongoing discussion about how/whether to actually enable *.dts to use
 that feature.

Hey finally! That's good news.

Regards,

Tony
--
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/3] pinctrl: add samsung pinctrl and gpiolib driver

[Tony Lindgren]

* Linus Walleij linus.wall...@linaro.org [120531 18:40]:
 On Thu, May 24, 2012 at 7:47 AM, Thomas Abraham
 thomas.abra...@linaro.org wrote:
 
  diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
  b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
 
 It would be nice if some DT person could review the bindings, but if
 nothing happens
 I will accept them as-is.

Looks OK to me, that's a bit slower way of parsing pins compared to
just register value pairs but allows naming them. And it was agreed
that it's up to the driver to define it's binding.
 
 This driver is special since it seems to keep all pin, group and
 function information
 in the device tree, but not like Tony is doing it in pinctrl-simple,
 if I understand
 correctly?

Looks like it's using static arrays which I was too using earlier.
That too should be OK for now, then at some point we can probably
have something generic to manage the pins for at least some drivers.

Regards,

Tony
 
--
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

[Tony Lindgren]

* Uwe Kleine-König u.kleine-koe...@pengutronix.de [120329 14:16]:
 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.

Acked-by: Tony Lindgren t...@atomide.com
--
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 23/31] ARM: amba: omap2: use common amba device initializers

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [120120 00:58]:
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/mach-omap2/emu.c |   26 ++
  1 files changed, 2 insertions(+), 24 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/emu.c b/arch/arm/mach-omap2/emu.c
 index 9c442e2..ce91aad 100644
 --- a/arch/arm/mach-omap2/emu.c
 +++ b/arch/arm/mach-omap2/emu.c
 @@ -30,29 +30,8 @@ MODULE_AUTHOR(Alexander Shishkin);
  #define ETB_BASE (L4_EMU_34XX_PHYS + 0x1b000)
  #define DAPCTL   (L4_EMU_34XX_PHYS + 0x1d000)
  
 -static struct amba_device omap3_etb_device = {
 - .dev= {
 - .init_name = etb,
 - },
 - .res= {
 - .start  = ETB_BASE,
 - .end= ETB_BASE + SZ_4K - 1,
 - .flags  = IORESOURCE_MEM,
 - },
 - .periphid   = 0x000bb907,
 -};
 -
 -static struct amba_device omap3_etm_device = {
 - .dev= {
 - .init_name = etm,
 - },
 - .res= {
 - .start  = ETM_BASE,
 - .end= ETM_BASE + SZ_4K - 1,
 - .flags  = IORESOURCE_MEM,
 - },
 - .periphid   = 0x102bb921,
 -};
 +static AMBA_APB_DEVICE(omap3_etb, etb, 0x000bb907, ETB_BASE, { }, NULL);
 +static AMBA_APB_DEVICE(omap3_etm, etm, 0x102bb921, ETM_BASE, { }, NULL);
  
  static int __init emu_init(void)
  {
 @@ -66,4 +45,3 @@ static int __init emu_init(void)
  }
  
  subsys_initcall(emu_init);
 -
 -- 
 1.7.4.4
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support

[Tony Lindgren]

* Dave Martin dave.mar...@linaro.org [111214 03:08]:
 If running in the Normal World on a TrustZone-enabled SoC, Linux
 does not have complete control over the L2 cache controller
 configuration.  The kernel cannot work reliably on such platforms
 without the l2x0 cache support code built in.

There are HS and GP omaps (High Security and General Purpose).
GP omaps do have full control of the L2. Also HS omaps most likely
provide control over enabling and disabling L2 depending how the
secure code is implemented.

BTW, the real problem is that because the secure code is implemented
in various ways, we don't really have any handling for it in Linux.

The SMI instruction numbers don't seem to be standardized at all,
and can mean different things on different boards, even different
board versions :(

Sounds like devicetree is the only safe way to deal with the L2
control options.

Regards,

Tony

 
 This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
 
 Thanks to Rob Herring for this suggestion. [1]
 
 Signed-off-by: Dave Martin dave.mar...@linaro.org
 
 [1] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
 ---
  arch/arm/mach-omap2/Kconfig |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index bb1b670..94e568a 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -41,11 +41,11 @@ config ARCH_OMAP4
   bool TI OMAP4
   default y
   depends on ARCH_OMAP2PLUS
 + select CACHE_L2X0
   select CPU_V7
   select ARM_GIC
   select HAVE_SMP
   select LOCAL_TIMERS if SMP
 - select MIGHT_HAVE_CACHE_L2X0
   select PL310_ERRATA_588369
   select PL310_ERRATA_727915
   select ARM_ERRATA_720789
 -- 
 1.7.4.1
 
--
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 v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support

[Tony Lindgren]

* Dave Martin dave.mar...@linaro.org [111214 09:58]:
 On Wed, Dec 14, 2011 at 10:14:25AM -0800, Tony Lindgren wrote:
  * Dave Martin dave.mar...@linaro.org [111214 03:08]:
   If running in the Normal World on a TrustZone-enabled SoC, Linux
   does not have complete control over the L2 cache controller
   configuration.  The kernel cannot work reliably on such platforms
   without the l2x0 cache support code built in.
  
  There are HS and GP omaps (High Security and General Purpose).
  GP omaps do have full control of the L2. Also HS omaps most likely
  provide control over enabling and disabling L2 depending how the
  secure code is implemented.
  
  BTW, the real problem is that because the secure code is implemented
  in various ways, we don't really have any handling for it in Linux.
  
  The SMI instruction numbers don't seem to be standardized at all,
  and can mean different things on different boards, even different
  board versions :(
  
  Sounds like devicetree is the only safe way to deal with the L2
  control options.
  
  Regards,
  
  Tony
  
   
   This patch unconditionally enables l2x0 support for the OMAP4 SoCs.
   
   Thanks to Rob Herring for this suggestion. [1]
   
   Signed-off-by: Dave Martin dave.mar...@linaro.org
   
   [1] 
   http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.html
   ---
arch/arm/mach-omap2/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
   
   diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
   index bb1b670..94e568a 100644
   --- a/arch/arm/mach-omap2/Kconfig
   +++ b/arch/arm/mach-omap2/Kconfig
   @@ -41,11 +41,11 @@ config ARCH_OMAP4
 bool TI OMAP4
 default y
 depends on ARCH_OMAP2PLUS
   + select CACHE_L2X0
 select CPU_V7
 select ARM_GIC
 select HAVE_SMP
 select LOCAL_TIMERS if SMP
   - select MIGHT_HAVE_CACHE_L2X0
 select PL310_ERRATA_588369
 select PL310_ERRATA_727915
 select ARM_ERRATA_720789
   -- 
   1.7.4.1
   
 
 To clarify, are you suggesting we retain this patch, or not?

I think we should keep L2 configurable for omaps until we have some
way of getting the configuration dynamically or from device tree.
 
 (If we only know what l2x0 support will be needed once the dts is
 parsed at runtime, there could be an argument for keeping the
 select CACHE_L2X0 here -- unless we have specific kconfigs for
 the different security variants of omap.)

Well we can detect if it's an HS omap, but we may not know what
SMI it uses for enabling and disabling L2.. That can depend on
the board version.

Is there some problem keeping MIGHT_HAVE_CACHE_L2X0? This is
pretty important from debugging cache issues point of view.

Regards,

Tony
--
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 v4 REPOST 3/5] omap4: Unconditionally require l2x0 L2 cache controller support

[Tony Lindgren]

* Rob Herring robherri...@gmail.com [111214 12:30]:
 
 On 12/14/2011 12:39 PM, Tony Lindgren wrote:
  
  I think we should keep L2 configurable for omaps until we have some
  way of getting the configuration dynamically or from device tree.
   
 
 This already exists with l2x0_of_init. OMAP just needs to start using
 it. It will initialize the l2 if present in the DT and skip it if not
 present.

That's great, that will allow doing the right thing with setting
up how to enable and disable it :) Considering that, this patch
should be OK to apply:

Acked-by: Tony Lindgren t...@atomide.com

--
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

[Tony Lindgren]

Hi,

* Linus Walleij linus.wall...@linaro.org [24 01:29]:
 On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren t...@atomide.com wrote:
 
  Note that with device tree things get simpler for muxing as we can
  get rid of the hardcoded grouping of pins in mux drivers. Instead of
  hardcoded pingroups, the groups can be created dynamically based on
  what the driver DT entries have.
 
 Yes, I know too little about DT to figure out how these should
 come in.
 
  The reason why we want to avoid hardcoded pin groups is because trying
  to map all the pad combinations in the pinmux driver is not a scalable
  way to go. And it's not even possible at least on omaps because of the
  huge number of combinations with alternative pins and multiple packages.
 
 Yes, that's a solid case!

So far it seems that device tree simplifies things here quite a bit in at
least two ways:

- We by default have automatically generated 1:1 mapping of devices to
  groups (of course others can be added too)

- We should be able to support new SoC packages with different pin on
  existing kernels, like distro kernels, just by modifying the the device
  tree data ;)
 
  FYI I'm playing with a DT based pinmux-simple.c driver that should
  be pretty generic and work for all kinds of hardware hopefully.
 
 I love it.

Still need few more days with these patches..
 
  It will be few days before I can post anything though, there are
  some pinctrl fwk issues to deal with first. Like the hardcoded
  pinmux_maps that assumes that dev entries are static. This means
  that multiple instances of pinmux drivers won't work..
 
 I'm not following, but I guess I will understand when I see the
 patches. The idea behind the current map concept is that you
 get either a string or struct device * to identify the pin controller
 and mapped device, that's as far as I thought it out, sorry for
 any inherent limitations, they're not intentional...

Yeah we can sort those out afterwards. We should probably pass over
the static board specific mapping as platform_data to the pinmux device
and make it be part of struct pinctrl_dev. Then new driver instances
can have their own pctldev-mapping and we can support both platform_data
and device tree based drivers on the same system. Anyways, I'll try to
get the initial patches working with just one instance to start with
so we have something to play
with.

Regards,

Tony
--
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] ARM: OMAP: Introduce local common.h files

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [11 07:42]:
 On Thu, Nov 10, 2011 at 03:33:47PM -0800, Tony Lindgren wrote:
  * Russell King - ARM Linux li...@arm.linux.org.uk [10 13:54]:
   Thanks, merged that into the series.  The updated OMAP patch updated is
   below, which has been moved to part 2.  Lastly, the final patch of part
   2 has been updated to delete the empty arch_reset(), so OMAP is now
   entirely free of arch_reset() references.  This leaves a total of 12
   references left to nobble.
  
  Great, good to hear.
 
 I've added this to the patch, as these no longer need to include this
 header.

OK thanks.

Tony
 
 diff --git a/arch/arm/mach-omap1/board-voiceblue.c 
 b/arch/arm/mach-omap1/board-voiceblue.c
 index fb61434..f83a502d 100644
 --- a/arch/arm/mach-omap1/board-voiceblue.c
 +++ b/arch/arm/mach-omap1/board-voiceblue.c
 @@ -28,7 +28,6 @@
  #include linux/export.h
  
  #include mach/hardware.h
 -#include mach/system.h
  #include asm/mach-types.h
  #include asm/mach/arch.h
  #include asm/mach/map.h
 diff --git a/arch/arm/mach-omap1/reset.c b/arch/arm/mach-omap1/reset.c
 index 8b1cc6e..91d199b 100644
 --- a/arch/arm/mach-omap1/reset.c
 +++ b/arch/arm/mach-omap1/reset.c
 @@ -5,7 +5,6 @@
  #include linux/io.h
  
  #include mach/hardware.h
 -#include mach/system.h
  #include plat/prcm.h
  
  void omap1_restart(char mode, const char *cmd)
 diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
 index b6c8cb5..626acfa 100644
 --- a/arch/arm/mach-omap2/prcm.c
 +++ b/arch/arm/mach-omap2/prcm.c
 @@ -25,7 +25,6 @@
  #include linux/delay.h
  #include linux/export.h
  
 -#include mach/system.h
  #include common.h
  #include plat/prcm.h
  #include plat/irqs.h
 
--
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

[PATCH] ARM: OMAP: Introduce local common.h files

[Tony Lindgren]

As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
there's no need to keep local prototypes in non-local headers.

Add mach-omap1/common.h and mach-omap2/common.h and move the
local prototypes there from plat/common.h and mach/omap4-common.h.

Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index 51bae31..1b37400 100644
---
Here's a patch that fixes the locality issues for MACHINE_START/END
functions at least.
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -35,7 +35,7 @@
 #include plat/mux.h
 #include plat/usb.h
 #include plat/board.h
-#include plat/common.h
+#include common.h
 #include mach/camera.h
 
 #include mach/ams-delta-fiq.h
diff --git a/arch/arm/mach-omap1/board-fsample.c 
b/arch/arm/mach-omap1/board-fsample.c
index 2317827..b9c4c0f 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -32,7 +32,7 @@
 #include plat/flash.h
 #include plat/fpga.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/board.h
 
 /* fsample is pretty close to p2-sample */
diff --git a/arch/arm/mach-omap1/board-generic.c 
b/arch/arm/mach-omap1/board-generic.c
index dc5b75d..7f41d7a 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -25,7 +25,7 @@
 #include plat/mux.h
 #include plat/usb.h
 #include plat/board.h
-#include plat/common.h
+#include common.h
 
 /* assume no Mini-AB port */
 
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index b334b14..7933b97 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -43,7 +43,7 @@
 #include plat/irda.h
 #include plat/usb.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/flash.h
 
 #include board-h2.h
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 74ebe72..04be2f8 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -45,7 +45,7 @@
 #include plat/usb.h
 #include plat/keypad.h
 #include plat/dma.h
-#include plat/common.h
+#include common.h
 #include plat/flash.h
 
 #include board-h3.h
diff --git a/arch/arm/mach-omap1/board-htcherald.c 
b/arch/arm/mach-omap1/board-htcherald.c
index 3e91baa..46fcfeb 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -41,7 +41,7 @@
 #include asm/mach/arch.h
 
 #include plat/omap7xx.h
-#include plat/common.h
+#include common.h
 #include plat/board.h
 #include plat/keypad.h
 #include plat/usb.h
diff --git a/arch/arm/mach-omap1/board-innovator.c 
b/arch/arm/mach-omap1/board-innovator.c
index 273153d..f99d11d 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -37,7 +37,7 @@
 #include plat/tc.h
 #include plat/usb.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/mmc.h
 
 /* At OMAP1610 Innovator the Ethernet is directly connected to CS1 */
diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index 6798b84..c643423 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -30,7 +30,7 @@
 #include plat/usb.h
 #include plat/board.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 #include plat/hwa742.h
 #include plat/lcd_mipid.h
 #include plat/mmc.h
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index c385927..a409dfc 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -51,7 +51,7 @@
 #include plat/usb.h
 #include plat/mux.h
 #include plat/tc.h
-#include plat/common.h
+#include common.h
 
 /* At OMAP5912 OSK the Ethernet is directly connected to CS1 */
 #define OMAP_OSK_ETHR_START0x04800300
diff --git a/arch/arm/mach-omap1/board-palmte.c 
b/arch/arm/mach-omap1/board-palmte.c
index f9c44cb..105292d 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -41,7 +41,7 @@
 #include plat/board.h
 #include plat/irda.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 
 #define PALMTE_USBDETECT_GPIO  0
 #define PALMTE_USB_OR_DC_GPIO  1
diff --git a/arch/arm/mach-omap1/board-palmtt.c 
b/arch/arm/mach-omap1/board-palmtt.c
index 11a9853..387a900 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -39,7 +39,7 @@
 #include plat/board.h
 #include plat/irda.h
 #include plat/keypad.h
-#include plat/common.h
+#include common.h
 
 #include linux/spi/spi.h
 #include linux/spi/ads7846.h
diff --git a/arch/arm/mach-omap1/board-palmz71.c 
b/arch/arm/mach-omap1/board-palmz71.c
index 4206157..df6d15e 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -41,7 +41,7 @@
 #include plat/board.h
 #include plat/irda.h
 #include plat/keypad.h

Re: [PATCH] ARM: OMAP: Introduce local common.h files

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [10 11:49]:
 On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
  As suggested by Russell King - ARM Linux li...@arm.linux.org.uk,
  there's no need to keep local prototypes in non-local headers.
  
  Add mach-omap1/common.h and mach-omap2/common.h and move the
  local prototypes there from plat/common.h and mach/omap4-common.h.
  
  Signed-off-by: Tony Lindgren t...@atomide.com
 
 Great, looks fine, thanks.  I suspect the chance of conflicts on this are
 about the same as the chance of conflicts with the rest of the restart
 series (in that, new platforms will need to be fixed for both these
 changes.)
 
 So, I suggest that I add it to my series so I can fix the OMAP changes
 there so stuff still builds - and then I can see about publishing a more
 stable branch in a couple of weeks for new platforms to base on.

OK, a stable branch is needed badly for this.. If possible please
publish some minimal stable base branch as soon as you can as pretty
much all omap patches need to be updated for this one.
 
 If you agree, could you put it in the patch system please?  Thanks.

Sounds good to me, it there now as patch 7159/1.

Regards,

Tony
--
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: Pet Peaves about Platform code, and arch_reset

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [07 16:11]:
 * Russell King - ARM Linux li...@arm.linux.org.uk [06 05:18]:
  Here's a list of my peaves about current platform code - which are
  causing me great issue when trying to clean up the arch_reset() stuff:
  
  1. Lack of trailing ',' on structure initializers
 This makes it much harder to add additional initializers at the end
 of existing initializers, and increases the risks of conflicts being
 caused due to more lines having to be modified.
  
  (This won't work directly because the tabs have been converted to space.
  The empty-looking [] contain a space plus a tab.)
  $ grep '[   ][  ]*\.[[:alnum:]_][[:alnum:]_]*[  ]*=[
  ]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm -r|wc -l
  768
  $ grep '[   ][  ]*\.[[:alnum:]_][[:alnum:]_]*[  ]*=[
  ]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm/*omap* -r|wc -l
  325
  
 Note that this is _far_ too big a problem - and trivial - to fix in
 a set of silly churn generating patches - it's a problem to be fixed
 as a part of _other_ changes to the files.
  
 But most importantly _stop_ introducing versions of this problem.
 
 Sounds like we need a spatch for this issue?

I guess spatch would need some patching to deal with this.. I tried
with something like:

@r@
identifier I, s, fld;
position p0,p;
expression E;
@@

struct I s =@p0 {
...
-   .fld@p = E,
+   .fld = E,
...
};

That catches them, but adds an extra comma in the beginning :)

--- a/ams-delta-fiq.c 2011-11-08 18:03:20.110707512 -0800
+++ b/ams-delta-fiq.c 2011-11-08 18:04:36.094948038 -0800
@@ -25,7 +25,7 @@
 #include mach/ams-delta-fiq.h
 
 static struct fiq_handler fh = {
-   .name   = ams-delta-fiq
+   ,.name = ams-delta-fiq,
 };
 
 /*

And it also messes up the formatting for other structs..

Anyways, I think I got most of these fixed for all ARM subarchitectures
in a pile of 72 patches, the stats are: 

486 files changed, 2296 insertions(+), 2296 deletions(-)

This is something people can then use as a base to start chipping away at
the problem. I'm thinking it may be possible to use this as a base for
search and replacement type work and then hopefully git mergetool will
pick the relevant changes when rebasing a working branch to the mainline.

I can also post the patches here if people want, but sounds like we're
not going to merge them as they are, but instead will slowly fix the
issue in other related patches?

I've pushed the patches into a git branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap formatting:

Web interface at:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=shortlog;h=refs/heads/formatting

Regards,

Tony
--
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: Pet Peaves about Platform code, and arch_reset

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [06 05:18]:
 Here's a list of my peaves about current platform code - which are
 causing me great issue when trying to clean up the arch_reset() stuff:
 
 1. Lack of trailing ',' on structure initializers
This makes it much harder to add additional initializers at the end
of existing initializers, and increases the risks of conflicts being
caused due to more lines having to be modified.
 
 (This won't work directly because the tabs have been converted to space.
 The empty-looking [] contain a space plus a tab.)
 $ grep '[   ][  ]*\.[[:alnum:]_][[:alnum:]_]*[  ]*=[
 ]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm -r|wc -l
 768
 $ grep '[   ][  ]*\.[[:alnum:]_][[:alnum:]_]*[  ]*=[
 ]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm/*omap* -r|wc -l
 325
 
Note that this is _far_ too big a problem - and trivial - to fix in
a set of silly churn generating patches - it's a problem to be fixed
as a part of _other_ changes to the files.
 
But most importantly _stop_ introducing versions of this problem.

Sounds like we need a spatch for this issue?
 
 2. Lack of consistent formatting for structure initializers within a
mach- subdirectory.  Some use tabs to align the '=' sign.  Others
use one space.  This makes a repeated paste of a new initializer
mismatch the rest of the formatting of the structure.
 
I _really_ don't care to fix the new initializer I'm introducing to
match the random formatting within a subdirectory.

This too could be fixes up using spatch?
 
 3. Files containing one data structure or function are quite an annoyance
when trying to do something like move arch_reset() out of the header
file into the platform .c code; this requires creating yet another
file containing one function, or consolidating the platform code
together first.  I've fixed clps711x for that (so I can convert it),
but left others.
 
 4. People who think that include files must be stored under a directory
with 'include' somewhere mentioned in its path.  This is a big one
and a *REAL* hate.  Include files _private_ to a group of source files
in a directory should live in the same directory as those files.
For instance, this should be zero because the 'map_io' function should
not be exported outside of the arch/arm/mach-* subdirectory:
 
 $ grep -l map_io arch/arm/mach-*/include/mach/*.h | wc -l
 21
 
Let's look at some specific cases:
 
 $ grep omap15xx_map_io arch/arm/mach-omap1 arch/arm/plat-omap/ -r
 arch/arm/mach-omap1/board-innovator.c:  omap15xx_map_io();
 arch/arm/mach-omap1/board-palmte.c: .map_io = omap15xx_map_io,
 arch/arm/mach-omap1/board-palmz71.c:.map_io = omap15xx_map_io,
 arch/arm/mach-omap1/board-voiceblue.c:  .map_io = omap15xx_map_io,
 arch/arm/mach-omap1/io.c:void __init omap15xx_map_io(void)
 arch/arm/mach-omap1/board-palmtt.c: .map_io = omap15xx_map_io,
 arch/arm/mach-omap1/board-fsample.c:omap15xx_map_io();
 arch/arm/mach-omap1/board-sx1.c:.map_io = omap15xx_map_io,
 arch/arm/mach-omap1/board-ams-delta.c:  .map_io = omap15xx_map_io,
 arch/arm/plat-omap/include/plat/io.h:void omap15xx_map_io(void);
 arch/arm/plat-omap/include/plat/io.h:static inline void omap15xx_map_io(void)
 
What is the point of the omap15xx_map_io prototype being is a
_completely_ different place to where it is defined?
 
The problem is where do I put a function prototype for omap1_restart()
amongst these header files for OMAP1 board files to pick up?  Better
still, don't tell me, but fix this stuff so that OMAP1 private stuff
is in a 'common.h' or 'board.h' header file in arch/arm/mach-omap1.

Yeah we should add arch/arm/mach-omap1/common.h for this.
 
 $ grep s5pv210_init_irq arch/arm -r
 arch/arm/mach-s5pv210/mach-aquila.c:.init_irq   = 
 s5pv210_init_irq,
 arch/arm/mach-s5pv210/mach-torbreck.c:  .init_irq   = 
 s5pv210_init_irq,
 arch/arm/mach-s5pv210/mach-goni.c:  .init_irq   = s5pv210_init_irq,
 arch/arm/mach-s5pv210/cpu.c:void __init s5pv210_init_irq(void)
 arch/arm/mach-s5pv210/mach-smdkc110.c:  .init_irq   = 
 s5pv210_init_irq,
 arch/arm/mach-s5pv210/mach-smdkv210.c:  .init_irq   = 
 s5pv210_init_irq,
 arch/arm/plat-samsung/include/plat/s5pv210.h:extern void 
 s5pv210_init_irq(void);
 
Again, what is the point of this lack of locality?  And more-over,
where the hell do I put a prototype for my new s5pv210_restart()
which is in arch/arm/mach-s5pv210/cpu.c ?  Again, don't tell me but
fix stuff so that the function prototypes etc are closer to their
definitions and uses.
 
There is no excuse for this kind of crap, other than people being
sheep and following idiotic and rediculous ideas like include files
must be under a directory called include.
 
 The arch_reset() branch, when published, will end with 

Re: [PATCH 2/2] arm: dt: Add device tree support for i2c instance 1 on exynos4 dt machine

[Tony Lindgren]

* G, Manjunath Kondaiah manj...@ti.com [110719 09:59]:
 On Tue, Jul 19, 2011 at 2:00 AM, Grant Likely grant.lik...@secretlab.ca 
 wrote:
 
  No, the i2c bus node should still appear in the SoC .dtsi file.  If a
  board doesn't use a particular i2c bus, then the board.dts file can
  add a status = disabled; property to the i2c bus node to disable it.
 
 that's right. I am referring to I2C slave devices. For a given SoC,
 two different
 boards can have different i2c slave devices with different slave
 address. In that case,
 it is better to have i2c child/slave nodes in board .dts file.

This is OK for now, but from bus/hwmod point of view we need to reset all
the unused devices as otherwise PM will never work properly.

Disabling each device in the board .dts file will never be done correctly
for most boards.. And on each board, probably 2/3 of the devices are unused
because of the pin limitations :)

So the disabling of unused devices should be done with a late_initcall and
controlled by kernel cmdline. We were thinking hwmod.disable=[0|1].

The late_initcall to disable unused device tree devices could also be
added later on to device tree core code.

Regards,

Tony
--
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 25/25] ARM: pm: omap34xx: convert to generic suspend/resume support

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [110622 08:24]:
 Convert sa11x0 to use the generic CPU suspend/resume support, rather
  ^^
Should be omap34xx above.

 than implementing its own version.  Tested on 3430 LDP.

Nice job with this series Russell!

Tony
--
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 2/5] ARM: P2V: avoid initializers and assembly using PHYS_OFFSET

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [110106 01:16]:
 On Thu, Jan 06, 2011 at 09:51:45AM +0100, Sascha Hauer wrote:
  As Russell noted this conflicts with the current i.MX branch. In current
  i.MX branch we have:
  
  -   .boot_params = PHYS_OFFSET + 0x100,
  +   .boot_params = MX51_PHYS_OFFSET + 0x100,
  
  PLAT_PHYS_OFFSET should be defined to MX51_PHYS_OFFSET, so it shouldn't
  matter which solution to the conflict we choose.
 
 I've actually dropped my modifications to this files as your change
 to them makes more sense longer term.

Acked-by: Tony Lindgren t...@atomide.com
--
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: Samsung SoCs: preparation for single kernel

[Tony Lindgren]

* Eric Miao eric.y.m...@gmail.com [100623 03:48]:
 On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park kmp...@infradead.org wrote:
  To Ben,
 
  I really need single kernel for s5pc110 (cortex A8) and s5pc210
  (cortex A9) at least.
  Fortunately arm move to these approaches recently. but current Samsung
  SoCs not prepare these one.
 
  So I wonder do you have a plan or how to address these issues?
  How to assign the address at resources and use it at runtime?
 
  Personally I want to use cpu_is_*. but you reject it to use.
  Other way is that we can create the base address variables and assign
  it at init time.
 
  Please give your opinions.
 
  Thank you,
  Kyungmin Park
 
  e.g., cpu_is_* usage at OMAP tree
 
  static void omap_init_mcspi(void)
  {
         if (cpu_is_omap44xx())
                 omap4_mcspi_fixup();
 
         platform_device_register(omap2_mcspi1);
         platform_device_register(omap2_mcspi2);
 
         if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx())
                 omap2_mcspi3_init();
 
         if (cpu_is_omap343x() || cpu_is_omap44xx())
                 omap2_mcspi4_init();
  }
 
 Just my two cents: cpu_is_*() can be used, but only when absolutely necessary.
 The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*()
 can be even reduced.
 
 I'm not sure if the above case is a good reference or not. The omap_init_mcspi
 is called from omap2_init_devices(), while the registration can actually be
 made into the board init code when that device is used (some of the McSPIs are
 not used, and it's not necessary to register them), and the differences be
 handled in the driver.

Few comments regarding the cpu_is_omap macros: The macros should really be
soc_is_omap() instead cpu_is_omap().

Also, sprinkling these too much makes the code messy and hard to patch for
new processors. So you should limit the use to very selected places during
init, then set some flag like OMAP_HAS_MCSPI2 | OMAP_HAS_MCSPI3 or something
similar.

Regards,

Tony
--
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