All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Alexander Graf <agraf@suse.de>,
	David Gibson <david@gibson.dropbear.id.au>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] ppc: Fix sam460ex devicetree when booting the Linux kernel
Date: Fri, 22 Jun 2018 19:34:20 -0700	[thread overview]
Message-ID: <20180623023420.GA28312@roeck-us.net> (raw)
In-Reply-To: <alpine.BSF.2.21.1806222322110.86811@zero.eik.bme.hu>

On Fri, Jun 22, 2018 at 11:37:30PM +0200, BALATON Zoltan wrote:
> 
> >>The version of the Linux kernel I've tried (which is from the Linux CD
> >>on ACube's site) did not try to access the power management register,
> >>neither any guest OSes I've tested with. Looks like it may be specific
> >>to the kernel config you're using.
> >>
> >Interesting. This is with the standard upstream kernel, using
> >canyonlands_defconfig.
> >The code seems to have been in the upstream kernel forever.
> 
> Maybe the Sam460ex specific image has some patches not in upstream kernel.
> 

Yes, it does. To start with, the DesignWare sata driver is different.

This is not the reason for the problem, though. canyonlands_defconfig
in the upstream kernel has CONFIG_SUSPEND enabled, but the configuration
used by aCube doesn't. The kernel code accessing the power management
registers is only enabled with CONFIG_SUSPEND.

> >>By the way, when I've tried with a more recent Linux kernel (4.15.10)
> >>I've noticed that the sm501 driver seemed like having endianness
> >>problems and thus did not find the chip, while it works with other older
> >>kernels made for sam460ex. I did not try to debug or bisect this yet. Do
> >>you know anything about that?
> >>
> >
> >No, I had not noticed. SM501 is disabled in the latest canyonlands_defconfig,
> >and I only use the serial console for my testing. It fails as far back as
> >3.18.y,
> >so I am not sure if this is a Linux or a qemu problem, or if it is a
> >problem that
> >was never fixed in the upstream kernel. What kernels did you try ?
> 

The problem is this (from the kernel diffs provided by aCube):

 #if defined(CONFIG_PPC32)
-#define smc501_readl(addr)             ioread32be((addr))
-#define smc501_writel(val, addr)       iowrite32be((val), (addr))
+#define smc501_readl(addr)             ioread32((addr))
+#define smc501_writel(val, addr)       iowrite32((val), (addr))
 #else
 #define smc501_readl(addr)             readl(addr)
 #define smc501_writel(val, addr)       writel(val, addr)

This is a bit fishy since the cpu is big endian and iowrite32be()
should be identical to iowrite32(), but apparently that is not the
case here. I don't think I'll have time to track this down, though.

Guenter

  reply	other threads:[~2018-06-23  2:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-22  4:47 [Qemu-devel] [PATCH] ppc: Fix sam460ex devicetree when booting the Linux kernel Guenter Roeck
2018-06-22  5:03 ` David Gibson
2018-06-22  7:52   ` BALATON Zoltan
2018-06-22 13:34     ` Guenter Roeck
2018-06-22 21:37       ` BALATON Zoltan
2018-06-23  2:34         ` Guenter Roeck [this message]
2018-06-23 20:55           ` BALATON Zoltan
2018-06-23 21:15             ` Guenter Roeck
2018-06-23 21:32               ` BALATON Zoltan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180623023420.GA28312@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=agraf@suse.de \
    --cc=balaton@eik.bme.hu \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.