Re: [PATCH v2 0/7] padata: parallelize deferred page init

2020-05-21 Thread Josh Triplett 
On Wed, May 20, 2020 at 02:26:38PM -0400, Daniel Jordan wrote:
> Please review and test, and thanks to Alex, Andrew, Josh, and Pavel for
> their feedback in the last version.

I re-tested v2:

Tested-by: Josh Triplett 

[0.231435] node 1 initialised, 24189223 pages in 32ms
[0.236718] node 0 initialised, 23398907 pages in 36ms

Re: [PATCH 5/9] powerpc: PCI_MSI needs PCI

2018-10-19 Thread Josh Triplett 
On Fri, Oct 19, 2018 at 02:09:48PM +0200, Christoph Hellwig wrote:
> Various powerpc boards select the PCI_MSI config option without selecting
> PCI, resulting in potentially not compilable configurations if the by
> default enabled PCI option is disabled.  Explicitly select PCI to ensure
> we always have valid configs.
[...]
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -24,6 +24,7 @@ config BLUESTONE
>   default n
>   select PPC44x_SIMPLE
>   select APM821xx
> + select PCI
>   select PCI_MSI
>   select PPC4xx_MSI
>   select PPC4xx_PCI_EXPRESS
> @@ -78,6 +79,7 @@ config KATMAI
>   select 440SPe
>   select PCI
>   select PPC4xx_PCI_EXPRESS
> + select PCI
>   select PCI_MSI

This case already had PCI selected a couple of lines above.

>   select PPC4xx_MSI
>   help
> @@ -219,6 +221,7 @@ config AKEBONO
>   select SWIOTLB
>   select 476FPE
>   select PPC4xx_PCI_EXPRESS
> + select PCI
>   select PCI_MSI
>   select PPC4xx_HSTA_MSI
>   select I2C
> -- 
> 2.19.1
>

Re: [PATCH v2 tip/core/rcu 02/39] rcu: Make arch select smp_mb__after_unlock_lock() strength

2017-04-17 Thread Josh Triplett 
On Mon, Apr 17, 2017 at 04:44:49PM -0700, Paul E. McKenney wrote:
> The definition of smp_mb__after_unlock_lock() is currently smp_mb()
> for CONFIG_PPC and a no-op otherwise.  It would be better to instead
> provide an architecture-selectable Kconfig option, and select the
> strength of smp_mb__after_unlock_lock() based on that option.  This
> commit therefore creates ARCH_WEAK_RELEASE_ACQUIRE, has PPC select it,
> and bases the definition of smp_mb__after_unlock_lock() on this new
> ARCH_WEAK_RELEASE_ACQUIRE Kconfig option.
> 
> Reported-by: Ingo Molnar <mi...@kernel.org>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> Cc: Peter Zijlstra <pet...@infradead.org>
> Cc: Will Deacon <will.dea...@arm.com>
> Cc: Boqun Feng <boqun.f...@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> Cc: Paul Mackerras <pau...@samba.org>
> Acked-by: Michael Ellerman <m...@ellerman.id.au>
> Cc: <linuxppc-dev@lists.ozlabs.org>

Seems sensible.

Reviewed-by: Josh Triplett <j...@joshtriplett.org>

>  arch/Kconfig | 3 +++
>  arch/powerpc/Kconfig | 1 +
>  include/linux/rcupdate.h | 6 +++---
>  3 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index cd211a14a88f..adefaf344239 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -320,6 +320,9 @@ config HAVE_CMPXCHG_LOCAL
>  config HAVE_CMPXCHG_DOUBLE
>   bool
>  
> +config ARCH_WEAK_RELEASE_ACQUIRE
> + bool
> +
>  config ARCH_WANT_IPC_PARSE_VERSION
>   bool
>  
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 97a8bc8a095c..7a5c9b764cd2 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -99,6 +99,7 @@ config PPC
>   select ARCH_USE_BUILTIN_BSWAP
>   select ARCH_USE_CMPXCHG_LOCKREF if PPC64
>   select ARCH_WANT_IPC_PARSE_VERSION
> + select ARCH_WEAK_RELEASE_ACQUIRE
>   select BINFMT_ELF
>   select BUILDTIME_EXTABLE_SORT
>   select CLONE_BACKWARDS
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index de88b33c0974..e6146d0074f8 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -1127,11 +1127,11 @@ do { \
>   * if the UNLOCK and LOCK are executed by the same CPU or if the
>   * UNLOCK and LOCK operate on the same lock variable.
>   */
> -#ifdef CONFIG_PPC
> +#ifdef CONFIG_ARCH_WEAK_RELEASE_ACQUIRE
>  #define smp_mb__after_unlock_lock()  smp_mb()  /* Full ordering for lock. */
> -#else /* #ifdef CONFIG_PPC */
> +#else /* #ifdef CONFIG_ARCH_WEAK_RELEASE_ACQUIRE */
>  #define smp_mb__after_unlock_lock()  do { } while (0)
> -#endif /* #else #ifdef CONFIG_PPC */
> +#endif /* #else #ifdef CONFIG_ARCH_WEAK_RELEASE_ACQUIRE */
>  
>  
>  #endif /* __LINUX_RCUPDATE_H */
> -- 
> 2.5.2
>

Re: [RFC] fs: add userspace critical mounts event support

2016-10-04 Thread Josh Triplett 
On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez  wrote:
> > I am not sure how/why a firmware loading daemon would be a better
> > idea now. What Marc describes that Josh proposed with signals for
> > userspcae seems more aligned with what we likely need
> 
> Quite frankly, I doubt you want a signal.
> 
> You will want to have some way to specify where the firmware files
> are. Right now we have "fw_path[]" which is hardcoded except for the
> first entry that can be set as a module parameter. But you'd probably
> want to expand on that, which implies some /sys or /proc interface.
> 
> And once you do that, wouldn't it make more sense to just make the
> "update the firmware path /proc/sys/kernel/fw_path file" make things
> re-search for firmware?

That could work, but it seems like overkill to allow changing the path,
rather than the simpler interface of just telling the one driver "go
ahead and direct-load your firmware now".  I definitely don't think it
should be a system-wide "mount event"; it should be a per-device "go
direct-load your firmware" poke from userspace.  That would solve the
"build-in the driver so it can start waking up slow monitors, but wait
to load the firmware until you have a filesystem" problem.  (And it
would avoid creating some unusual driver-specific late-firmware-load
mechanism.)

That said, the Chrome OS folks apparently have some mechanism where they
mount a tmpfs over /lib/firmware to let userspace choose firmware at
runtime, so perhaps the path-changing mechanism would help there.  Kees?

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

2016-05-19 Thread Josh Triplett 
On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote:
> On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote:
> > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote:
> > > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
> > > > On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
> > > > > On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
> > > > > > The option "-soundhw pcspk" gives me a error on PPC as follow:
> > > > > > 
> > > > > > qemu-system-ppc64: ISA bus not available for pcspk
> > > > > > 
> > > > > > , which means this option doesn't work on ppc by default. So simply 
> > > > > > make
> > > > > > this an x86-specific option via identify_qemu_args().
> > > > > > 
> > > > > > Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
> > > > > 
> > > > > The emulated system for RCU testing does not need sound hardware at 
> > > > > all.
> > > > > Paul added this option in commit
> > > > > 16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
> > > > > hardware, saying that '"-soundhw pcspk" makes the script a bit less
> > > > > dependent on odd audio libraries being installed'.  Unfortunately, it
> > > > > looks like there isn't a "-soundhw none".  As far as I can tell,
> > > > > currently the only way to completely eliminate sound hardware is to 
> > > > > pass
> > > > > "-nodefaults" and then explicitly specify each desired device; while
> > > > > that would solve the issue, it would likely introduce *more*
> > > > > hardware-specific command-line options...
> > > > > 
> > > > > I've filed two feature requests on upstream qemu to make this simpler:
> > > > > https://bugs.launchpad.net/qemu/+bug/1583420 and
> > > > > https://bugs.launchpad.net/qemu/+bug/1583421 .
> > > > > 
> > > > > Paul, what did you mean by "dependent on odd audio libraries"?  Did 
> > > > > you
> > > > > mean in the guest or the host?  And either way, is this something that
> > > > > could potentially be solved another way?
> > > > 
> > > > If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
> > > > without this option, but I don't recall the exact error message.
> > > > I chalked it up to my ignorance of qemu, but I would very much welcome
> > > > some way to not have to specify irrelevant hardware.  So thank you very
> > > > much for filing the bugs!
> > > 
> > > According to qemu upstream, qemu doesn't enable any sound hardware by
> > > default, so I can't think of any obvious reason why adding "-soundhw
> > > pcspkr" would make the rcutorture VM boot.  Did qemu refuse to run at
> > > all, or did the VM start but fail during the boot process?
> > > 
> > > Could you check if you can currently run without this option?  If so,
> > > perhaps we should just drop it for now.
> > 
> > Will do!  As soon as the current test completes.
> 
> And it now works just fine without the "-soundhw pcspkr".  Search me!

In that case, can you replace the patch in this series making "-soundhw
pcspkr" target-specific with one removing "-soundhw pcspkr"?

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

2016-05-19 Thread Josh Triplett 
On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote:
> On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote:
> > On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
> > > The option "-soundhw pcspk" gives me a error on PPC as follow:
> > > 
> > > qemu-system-ppc64: ISA bus not available for pcspk
> > > 
> > > , which means this option doesn't work on ppc by default. So simply make
> > > this an x86-specific option via identify_qemu_args().
> > > 
> > > Signed-off-by: Boqun Feng <boqun.f...@gmail.com>
> > 
> > The emulated system for RCU testing does not need sound hardware at all.
> > Paul added this option in commit
> > 16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
> > hardware, saying that '"-soundhw pcspk" makes the script a bit less
> > dependent on odd audio libraries being installed'.  Unfortunately, it
> > looks like there isn't a "-soundhw none".  As far as I can tell,
> > currently the only way to completely eliminate sound hardware is to pass
> > "-nodefaults" and then explicitly specify each desired device; while
> > that would solve the issue, it would likely introduce *more*
> > hardware-specific command-line options...
> > 
> > I've filed two feature requests on upstream qemu to make this simpler:
> > https://bugs.launchpad.net/qemu/+bug/1583420 and
> > https://bugs.launchpad.net/qemu/+bug/1583421 .
> > 
> > Paul, what did you mean by "dependent on odd audio libraries"?  Did you
> > mean in the guest or the host?  And either way, is this something that
> > could potentially be solved another way?
> 
> If I remember correctly, Ubuntu 14.04 qemu refused to run the guest
> without this option, but I don't recall the exact error message.
> I chalked it up to my ignorance of qemu, but I would very much welcome
> some way to not have to specify irrelevant hardware.  So thank you very
> much for filing the bugs!

According to qemu upstream, qemu doesn't enable any sound hardware by
default, so I can't think of any obvious reason why adding "-soundhw
pcspkr" would make the rcutorture VM boot.  Did qemu refuse to run at
all, or did the VM start but fail during the boot process?

Could you check if you can currently run without this option?  If so,
perhaps we should just drop it for now.

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

2016-05-18 Thread Josh Triplett 
On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote:
> I spend some time to make tools/testing/selftest/rcutorture run on PPC,
> here are some documention and fixes made while I was trying.
> 
> The scripts are able to run and get results on PPC, however please
> note there are some stalls even build errors that could be found
> by the tests currently.
> 
> As I'm certainly not an expert of qemu or bash programming, there
> may be something I am missing in those patches. So tests and comments
> are welcome ;-)
> 
> Regards,
> Boqun
> 
> Boqun Feng (4):
>   rcutorture/doc: Add a new way to create initrd using dracut
>   rcutorture: Use vmlinux as the fallback kernel image
>   rcutorture: Make -soundhw a x86 specific option
>   rcutorture: Don't specify the cpu type of QEMU on PPC

All four of these seem reasonable to me:
Reviewed-by: Josh Triplett <j...@joshtriplett.org>

I responded to the -soundhw patch, trying to track down why that option
was needed in the first place, and seeking a solution that doesn't
require adding to the set of target-specific options.  But I don't think
that investigation should block your fix.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

2016-05-18 Thread Josh Triplett 
On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote:
> The option "-soundhw pcspk" gives me a error on PPC as follow:
> 
> qemu-system-ppc64: ISA bus not available for pcspk
> 
> , which means this option doesn't work on ppc by default. So simply make
> this an x86-specific option via identify_qemu_args().
> 
> Signed-off-by: Boqun Feng <boqun.f...@gmail.com>

The emulated system for RCU testing does not need sound hardware at all.
Paul added this option in commit
16c77ea7d0f4a74e49009aa2d26c275f7f93de7c to disable the default sound
hardware, saying that '"-soundhw pcspk" makes the script a bit less
dependent on odd audio libraries being installed'.  Unfortunately, it
looks like there isn't a "-soundhw none".  As far as I can tell,
currently the only way to completely eliminate sound hardware is to pass
"-nodefaults" and then explicitly specify each desired device; while
that would solve the issue, it would likely introduce *more*
hardware-specific command-line options...

I've filed two feature requests on upstream qemu to make this simpler:
https://bugs.launchpad.net/qemu/+bug/1583420 and
https://bugs.launchpad.net/qemu/+bug/1583421 .

Paul, what did you mean by "dependent on odd audio libraries"?  Did you
mean in the guest or the host?  And either way, is this something that
could potentially be solved another way?

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] srcu: Isolate srcu sections using CONFIG_SRCU

2015-01-04 Thread Josh Triplett 
linux-s...@vger.kernel.org
Message-ID: ea3b4ec8-5e29-4da3-b826-52aba92d7...@joshtriplett.org

On January 4, 2015 8:14:16 AM PST, Paul E. McKenney 
paul...@linux.vnet.ibm.com wrote:
On Sun, Jan 04, 2015 at 08:35:52PM +1100, Michael Ellerman wrote:
 On Tue, 2014-12-30 at 13:54 -0500, Pranith Kumar wrote:
  On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra
pet...@infradead.org wrote:
   On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
   Isolate the SRCU functions and data structures within
CONFIG_SRCU so that there
   is a compile time failure if srcu is used when not enabled. This
was decided to
   be better than waiting until link time for a failure to occur.
  
   Why?
  
  This is part of the kernel tinification efforts. The first patch
was
  posted here: https://lkml.org/lkml/2014/12/4/848. This patch
enables a
  compile time failure instead of a link time failure.
 
 The punch line was:
 
   so the savings are about ~2000 bytes.
 
 Which is utterly not worth the effort IMO. There have got to be more
attractive
 targets for tinification than this.

There probably are.  But if the tinification effort is to come anywhere
near reaching its goals, it is going to need 2000-byte savings,
especially
on the small systems that are this effort's main target.

That said, Peter's suggestion of falling back to the link-time
diagnostic
does simplify things a bit, and might be a good approach.

Agreed on both fronts; I don't think we should add any significant complexity 
just to turn link errors into compile errors.

- Josh Triplett

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] drivers: tty: Mark the function hvc_poll_init() as static in hvc_console.c

2013-12-16 Thread Josh Triplett 
On Mon, Dec 16, 2013 at 04:31:28PM +0530, Rashika Kheria wrote:
 Mark the function hvc_poll_init() as static in hvc/hvc_console.c because
 it is not used outside this file.
 
 This eliminates the following warning in hvc/hvc_console.c:
 drivers/tty/hvc/hvc_console.c:791:5: warning: no previous prototype for 
 ‘hvc_poll_init’ [-Wmissing-prototypes]
 
 Signed-off-by: Rashika Kheria rashika.khe...@gmail.com

Reviewed-by: Josh Triplett j...@joshtriplett.org

  drivers/tty/hvc/hvc_console.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
 index 9eba119..50b4688 100644
 --- a/drivers/tty/hvc/hvc_console.c
 +++ b/drivers/tty/hvc/hvc_console.c
 @@ -788,7 +788,7 @@ static int hvc_tiocmset(struct tty_struct *tty,
  }
  
  #ifdef CONFIG_CONSOLE_POLL
 -int hvc_poll_init(struct tty_driver *driver, int line, char *options)
 +static int hvc_poll_init(struct tty_driver *driver, int line, char *options)
  {
   return 0;
  }
 -- 
 1.7.9.5
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] sm501: When registering the GPIO, turn on the GPIO unit's power

2011-07-05 Thread Josh Triplett 
When attempting to use GPIO via the sm501 unit on the TQM5200 board,
GPIO operations would only function if during the same boot u-boot's
fkt led command had initialized the sm501.  Comparing the sm501's
registers with and without running the fkt led command turned up one
significant difference: u-boot had enabled the GPIO power gate.
Changing the Linux sm501 driver to enable the GPIO power gate allows
GPIO to work without first initializing it with u-boot.

Signed-off-by: Josh Triplett j...@joshtriplett.org
---
 drivers/mfd/sm501.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index df3702c..d7a0ab9 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -1089,6 +1089,7 @@ static int __devinit sm501_register_gpio(struct 
sm501_devdata *sm)
goto err_low_chip;
}
 
+   sm501_unit_power(sm-dev, SM501_GATE_GPIO, 1);
gpio-registered = 1;
 
return 0;
@@ -1118,6 +1119,8 @@ static void sm501_gpio_remove(struct sm501_devdata *sm)
if (!sm-gpio.registered)
return;
 
+   sm501_unit_power(sm-dev, SM501_GATE_GPIO, 0);
+
ret = gpiochip_remove(gpio-low.gpio);
if (ret)
dev_err(sm-dev, cannot remove low chip, cannot tidy up\n);
-- 
1.7.5.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Hooking up SM501 on TQM5200 (MPC5200) board via device tree?

2011-06-07 Thread Josh Triplett 
On Fri, Jun 03, 2011 at 02:51:38PM -0600, Grant Likely wrote:
 On Tue, May 31, 2011 at 10:07:01PM -0700, Josh Triplett wrote:
  We have a TQM5200 board, which has GPIO lines hooked up to an SM501.
  I've managed to come up with the following patch to the tqm5200 device
  tree, which manages to convince the sm501 driver to attach an sm501-fb:
  
  --- a/arch/powerpc/boot/dts/tqm5200.dts  2009-11-23 03:13:27.0 -0800
  +++ b/arch/powerpc/boot/dts/tqm5200.dts  2011-05-31 22:00:28.000580627 -0700
  @@ -177,7 +177,8 @@
  compatible = fsl,mpc5200-lpb,simple-bus;
  #address-cells = 2;
  #size-cells = 1;
  -   ranges = 0 0 0xfc00 0x0200;
  +   ranges = 0 0 0xfc00 0x0200
  + 1 0 0xe000 0x0400;
   
  flash@0,0 {
  compatible = cfi-flash;
  @@ -187,6 +188,13 @@
  #size-cells = 1;
  #address-cells = 1;
  };
  +
  +   display@1,0 {
  +   compatible = smi,sm501;
  +   reg = 1 0x 0x0080
  +  1 0x03e0 0x0020;
  +   interrupts = 1 1 3;
  +   };
  };
   
  pci@fd00 {
  
  
  However, this doesn't hook up the sm501-gpio bits.  Reading the sm501
  driver carefully, it looks like it only hooks up sm501-gpio if it has
  platform_data available which sets some flags and other information.
  So, if I understand correctly, hooking up sm501-gpio would require
  adding functionality the driver to get the GPIO information from the
  device tree in preference to the platform_data, if available, and fall
  back to the platform_data for existing users?
  
  What should the necessary device tree properties look like to replace
  sm501_initdata?
  
  - Josh Triplett
 
 You need to look at Documentation/devicetree/bindings/gpio/gpio.txt.
 
 Also, you need to add bits to the sm501-gpio driver to register a
 dynamically allocated range of gpio pins and to populate the
 gpiochip-of_node pointer.  If that points at a device tree node, then
 the core code will take care of setting up translation for you.

What would the resulting device tree look like, given that the sm501
driver handles several different types of devices?  sm501 doesn't have a
separate gpio driver; it just has a flag to enable GPIO.  The GPIO
controller also doesn't have independent resources; as far as I can
tell, the sm501 knows everything it needs to know in order to drive the
gpio, except the boolean presence or absence of gpio.

Currently, to get the sm501 hooked up at all, I wrote this:

display@1,0 {
compatible = smi,sm501;
reg = 1 0x 0x0080
   1 0x03e0 0x0020;
interrupts = 1 1 3;
};

To hook up the gpio, would I nest an entire gpio@... { ...;
gpio-controller; } stanza inside that or next to that, or just add the
gpio-controller; and #gpio-cells lines inside the existing stanza for
the sm501?

Does the gpio@ bit have any semantic significance, or just the
gpio-controller line and the compatible line?

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Hooking up SM501 on TQM5200 (MPC5200) board via device tree?

2011-05-31 Thread Josh Triplett 
We have a TQM5200 board, which has GPIO lines hooked up to an SM501.
I've managed to come up with the following patch to the tqm5200 device
tree, which manages to convince the sm501 driver to attach an sm501-fb:

--- a/arch/powerpc/boot/dts/tqm5200.dts  2009-11-23 03:13:27.0 -0800
+++ b/arch/powerpc/boot/dts/tqm5200.dts  2011-05-31 22:00:28.000580627 -0700
@@ -177,7 +177,8 @@
compatible = fsl,mpc5200-lpb,simple-bus;
#address-cells = 2;
#size-cells = 1;
-   ranges = 0 0 0xfc00 0x0200;
+   ranges = 0 0 0xfc00 0x0200
+ 1 0 0xe000 0x0400;
 
flash@0,0 {
compatible = cfi-flash;
@@ -187,6 +188,13 @@
#size-cells = 1;
#address-cells = 1;
};
+
+   display@1,0 {
+   compatible = smi,sm501;
+   reg = 1 0x 0x0080
+  1 0x03e0 0x0020;
+   interrupts = 1 1 3;
+   };
};
 
pci@fd00 {


However, this doesn't hook up the sm501-gpio bits.  Reading the sm501
driver carefully, it looks like it only hooks up sm501-gpio if it has
platform_data available which sets some flags and other information.
So, if I understand correctly, hooking up sm501-gpio would require
adding functionality the driver to get the GPIO information from the
device tree in preference to the platform_data, if available, and fall
back to the platform_data for existing users?

What should the necessary device tree properties look like to replace
sm501_initdata?

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash

2010-03-29 Thread Josh Triplett 
On Mon, Mar 29, 2010 at 08:42:08PM +0200, Albrecht Dreß wrote:
 Am 29.03.10 00:24 schrieb(en) Josh Triplett:
 We have the MPC5200C rev of the board, not the MPC5200B rev which
 
 Ummm - I didn't know that there is a 5200C available.  The Freescale web site 
 only mentions the 5200 and the 5200B.  Do you have any pointers to data 
 sheets/docs?

I don't know the details; just repeating what the hardware team told me.
:)  We may have the revisions and suffixes mixed up, or we may have run
into some terminology difference between the TQM5200 and the MPC5200.

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash

2010-03-28 Thread Josh Triplett 
On Sat, Mar 27, 2010 at 06:44:55PM +0100, Wolfgang Denk wrote:
 In message 20100326225916.ga5...@feather you wrote:
  However, according to one of our hardware hackers, Andrew Greenberg
  (CCed), the STK5200 development breakout board for the TQM5200 *does*
  have the DMA pins wired up correctly, at least according to its
  schematic.  That doesn't guarantee that the board matches the schematic,
  of course.
 
 We tested CF cards for DMA support some time ago, and IIRC this
 included the STK5200. Situation was that only very few CF cards
 actually support DMA (even if they advertise it on the label).

How very odd and disappointing.

So a CF card might advertise DMA on its label and feature set, and
show DMA modes in hdparm's info dump, but break when actually using DMA
modes?

Do you know of any specific CF cards which *do* support DMA?

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash

2010-03-28 Thread Josh Triplett 
On Sat, Mar 27, 2010 at 02:22:08PM +0100, Albrecht Dreß wrote:
 Am 26.03.10 23:59 schrieb(en) Josh Triplett:
 [snip]
 Any other ideas for things we could check to try to track down this problem?
 
 Might your issue be related to this thread: 
 http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078757.html?

We have the MPC5200C rev of the board, not the MPC5200B rev which
apparently had many problems like the ones described in that thread.  I
can't rule out other crazy board errata we don't know about, though. :)

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash

2010-03-26 Thread Josh Triplett 
On Fri, Mar 26, 2010 at 12:22:32PM -0600, Grant Likely wrote:
 On Tue, Mar 16, 2010 at 11:17 PM, Josh Triplett j...@joshtriplett.org wrote:
  Hello,
 
  We've tried both 2.6.33 and DENX-v2.6.33.1, and we haven't managed to
  successfully use any form of DMA with the TQM5200 and a CompactFlash
  card.  We know the CF card supports DMA (or, at least, it says UDMA
  right on the card, and various reports say Lexar Professional CF cards
  do DMA), but the kernel always puts the card in PIO4 mode.  We tried
  libata.force=mwdma2 and libata.force=udma2 , and many other modes, but
  this always led to failures like this:
 
  [   31.994311] ata1: lost interrupt (Status 0x58)
  [   32.020435] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 
  frozen
  [   32.027712] ata1.00: failed command: READ DMA
  [   32.032236] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 
  4096 in
  [   32.032249]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 
  (timeout)
  [   32.047212] ata1.00: status: { DRDY }
  [   32.051050] ata1: soft resetting link
  [   32.218796] ata1.00: FORCE: xfer_mask set to udma2
  [   32.230618] ata1.00: configured for UDMA/33
  [   32.235000] ata1.00: device reported invalid CHS sector 0
  [   32.240629] ata1: EH complete
  [   62.994310] ata1: lost interrupt (Status 0x58)
  [   63.020443] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 
  frozen
  [   63.027722] ata1.00: failed command: READ DMA
  [   63.032246] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 
  4096 in
  [   63.032259]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 
  (timeout)
  [   63.047221] ata1.00: status: { DRDY }
  [   63.051060] ata1: soft resetting link
  [   63.218778] ata1.00: FORCE: xfer_mask set to udma2
  [   63.238603] ata1.00: configured for UDMA/33
  [   63.242978] ata1.00: device reported invalid CHS sector 0
  [   63.248609] ata1: EH complete
 
  We have the MPC5200C revision of the silicon.
 
  Does this sound like a known issue?  Can we do anything to troubleshoot
  this further?
 
 Not all CF adapters have all the pins wired up that are needed for
 *DMA modes.  That is the most likely problem.

True, but we bought a card that specifically advertises support for
UDMA, and says UDMA right on the card's label.

http://store.lexar.com/?productid=CF8GB-300-381

It seems unlikely, though not impossible, that they would have screwed
up that badly. :)

By the way, we've also tested an IDE hard drive on this board, and it
does UDMA2 just fine.

Any thoughts on how we could try to solve this problem?

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash

2010-03-26 Thread Josh Triplett 
On Fri, Mar 26, 2010 at 11:17:07PM +0100, Wolfgang Wegner wrote:
 Hi Josh,
 
 On Fri, Mar 26, 2010 at 02:32:02PM -0700, Josh Triplett wrote:
  On Fri, Mar 26, 2010 at 12:22:32PM -0600, Grant Likely wrote:
   
   Not all CF adapters have all the pins wired up that are needed for
   *DMA modes.  That is the most likely problem.
  
  True, but we bought a card that specifically advertises support for
  UDMA, and says UDMA right on the card's label.
  
  http://store.lexar.com/?productid=CF8GB-300-381
 
 Grant was referring to the adapter, not the card!
 
 In fact I still have to see a single CF-to-IDE adapter that does
 have the wires needed for (U)DMA without me soldering them in place...

Oh!  OK, that makes more sense.

However, according to one of our hardware hackers, Andrew Greenberg
(CCed), the STK5200 development breakout board for the TQM5200 *does*
have the DMA pins wired up correctly, at least according to its
schematic.  That doesn't guarantee that the board matches the schematic,
of course.

Any other ideas for things we could check to try to track down this
problem?

- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev