All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: unlisted-recipients:; (no To-header on input)
Cc: Ohad Ben-Cohen <ohad@wizery.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Remoteproc v3.10 arm-microblaze
Date: Wed, 17 Jul 2013 14:16:34 +0200	[thread overview]
Message-ID: <51E68B22.9070704@monstr.eu> (raw)
In-Reply-To: <2dca3652-e141-4f9e-934e-29b7c4334b41@CH1EHSMHS037.ehs.local>

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

Hi,

On 07/17/2013 01:37 PM, Michal Simek wrote:
> Hi Ohad,
> 
> I am working on another remoteproc driver.
> Currently less problematic than arm-arm.
> It is arm to microblaze on zynq.
> 
> I have two problems:
> 1. I need to allocate carveout first because my firmware must be added to that
> space first. (I don't have any other mapping mechanism ready for use)
> I have simple solution I am calling rproc_handle_resources in rproc_fw_config_virtio()
> just for carveouts before rproc_count_vrings_handler and rproc_vdev_handler are called
> which ensure that carveout is allocated first.
> 
> 2. I am getting problem with rproc_handle_vdev().
> Here is the flow which I see:
> request_firmware_nowait() calls
> rproc_fw_config_virtio() calls
> rproc_handle_vdev() calls
> rproc_add_virtio_dev() calls
> register_virtio_device() calls dev->config->reset() without setup pointer rproc->table_ptr().
> 
> But rproc->table_ptr is setup in rproc_fw_boot()
> which is called from rproc_boot() much later.
> 
> Which is causing that all rproc_virtio_config_ops operations
> are using incorrect table_ptr().
> Problematic for me are rproc_virtio_get_status, rproc_virtio_set_status
> and especially rproc_virtio_reset();
> 
> And with BUG_ON I am getting problem virtio_dev_remove() where status should
> be zero - WARN_ON_ONCE(dev->config->get_status(dev));
> 
> Below is log with some of my debug messages. (comments explain what's going on there)

Let me correct myself. It is caused by switching from loaded_table back to cached_table
in rproc_shutdown where old cached_table is probably used and there are probably be still old values.

What's the purpose of cached_table? Shouldn't be synchronized with loaded one in rproc shutdown?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

      reply	other threads:[~2013-07-17 12:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 11:37 Remoteproc v3.10 arm-microblaze Michal Simek
2013-07-17 12:16 ` Michal Simek [this message]

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=51E68B22.9070704@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ohad@wizery.com \
    /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.