All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Meng <bmeng.cn@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH] x86: spi: Only use the fast SPI peripheral when support
Date: Tue, 31 Mar 2020 17:49:59 +0800	[thread overview]
Message-ID: <CAEUhbmVwz-A9En4FV6ybyDq=unHdvsKGQU1K8M+j71=1_rW7vg@mail.gmail.com> (raw)
In-Reply-To: <CAPnjgZ2CM7eOATgh4fqJpm8ev3YveyMWA-rRA_iJAZvTF51PTQ@mail.gmail.com>

Hi Simon,

On Tue, Mar 31, 2020 at 7:57 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Mon, 30 Mar 2020 at 03:42, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Sun, Mar 29, 2020 at 4:58 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Thu, 26 Mar 2020 at 10:38, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, Mar 27, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > HI Bin,
> > > > >
> > > > > On Wed, 25 Mar 2020 at 01:25, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Tue, Mar 24, 2020 at 9:45 PM Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > At present we query the memory map on boards which don't support it. Fix
> > > > > > > this by only doing it on Apollo Lake.
> > > > > > >
> > > > > >
> > > > > > I wonder isn't this check already covered in mrccache_get_region() below:
> > > > > >
> > > > > > ret = dm_spi_get_mmap(dev, &map_base, &map_size, &offset);
> > > > > > if (!ret) {
> > > > > > entry->base = map_base;
> > > > > > } else {
> > > > > > ret = dev_read_u32_array(dev, "memory-map", reg, 2);
> > > > > > if (ret)
> > > > > > return log_msg_ret("Cannot find memory map\n", ret);
> > > > > > entry->base = reg[0];
> > > > > > }
> > > > >
> > > > > Yes it is, so long as dm_spi_get_mmap() returns an error, as it does
> > > > > with my patch.
> > > >
> > > > So does ich_get_mmap_bus() returns 0 on chromebook_link?
> > >
> > > Well on link the SPI peripheral is not a PCI device but a child of the
> > > PCH. It is possible to read the registers but at present this only
> > > works once you have the mmio_base (i.e. the PCH device is probed).
> > > This function needs to work before probing (since FSP-S access needs
> > > to happen without probing PCI).
> > >
> > > I suspect it would be possible to read the PCH base without probing
> > > it, but it does add quite a bit of special-case code. What do you
> > > think?
> >
> > I've looked at this. So this function mrccache_get_region() is broken
> > on Minnowmax too. The call to uclass_find_first_device() returns
> > nothing because SPI flash is not probed hence no SF device is found.
>
> OK, so add to the DT, or do something else?

There is already "memor-map" propert (see below) y in Chromebook DTS
so I am not sure what else needs to be added to the DT, as you
mentioned?

spi: spi {
#address-cells = <1>;
#size-cells = <0>;
compatible = "intel,ich9-spi";
u-boot,dm-pre-reloc;
spi-flash at 0 {
#size-cells = <1>;
#address-cells = <1>;
u-boot,dm-pre-reloc;
reg = <0>;
compatible = "winbond,w25q64",
"jedec,spi-nor";
memory-map = <0xff800000 0x00800000>;
rw-mrc-cache {
label = "rw-mrc-cache";
reg = <0x003e0000 0x00010000>;
u-boot,dm-pre-reloc;
};
};
};

So isn't the failure on Link caused by uclass_find_first_device()? I
think replacing uclass_find_first_device() with uclass_first_device()
will fix failures for at least Minnowmax? The comment says:

/*
* Find the flash chip within the SPI controller node. Avoid probing
* the device here since it may put it into a strange state where the
* memory map cannot be read.
*/

What issue did you see if we probe the SPI controller and flash?

Regards,
Bin

  reply	other threads:[~2020-03-31  9:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 13:45 [PATCH] x86: spi: Only use the fast SPI peripheral when support Simon Glass
2020-03-25  7:25 ` Bin Meng
2020-03-26 16:19   ` Simon Glass
2020-03-26 16:22     ` Bin Meng
2020-03-28 20:04       ` Simon Glass
2020-03-28 20:58       ` Simon Glass
2020-03-30  9:41         ` Bin Meng
2020-03-30 23:56           ` Simon Glass
2020-03-31  9:49             ` Bin Meng [this message]
2020-03-31 13:16               ` Simon Glass
2020-04-19 19:14                 ` Simon Glass
2020-04-20 10:01                   ` Bin Meng
2020-04-23  7:36 ` Bin Meng

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='CAEUhbmVwz-A9En4FV6ybyDq=unHdvsKGQU1K8M+j71=1_rW7vg@mail.gmail.com' \
    --to=bmeng.cn@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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.