From: Sudeep Dutt <sudeep.dutt@intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sudeep Dutt <sudeep.dutt@intel.com>,
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
Arnd Bergmann <arnd@arndb.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Ashutosh Dixit <ashutosh.dixit@intel.com>,
Rob Landley <rob@landley.net>,
Caz Yokoyama <Caz.Yokoyama@intel.com>,
Dasaratharaman Chandramouli
<dasaratharaman.chandramouli@intel.com>
Subject: Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
Date: Fri, 06 Sep 2013 11:41:03 -0700 [thread overview]
Message-ID: <1378492863.107744.69.camel@localhost> (raw)
In-Reply-To: <20130906050157.GF28806@kroah.com>
On Thu, 2013-09-05 at 22:01 -0700, Greg Kroah-Hartman wrote:
> On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote:
> > +What: /sys/class/mic/mic(x)/firmware
> > +Date: August 2013
> > +KernelVersion: 3.11
> > +Contact: Sudeep Dutt <sudeep.dutt@intel.com>
> > +Description:
> > + When read, this sysfs entry provides the path name under
> > + /lib/firmware/ where the firmware image to be booted on the
> > + card can be found. The entry can be written to change the
> > + firmware image location under /lib/firmware/.
>
> I don't understand, is the path under the HOST device, or the Client
> device's disk? Why do you need to change the path on the HOST? What's
> wrong with the existing firmware path selection we have in the kernel?
>
The path is on the host. The card does not have a physical persistent
disk device. Our customers like the flexibility of changing the card
firmware/ramdisk contents and file names for individual MIC cards. This
flexibility is not possible with a static set of firmware file names in
the kernel for all cards.
Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs,
card boot is initiated via the "state" sysfs entry. The host driver then
obtains the contents of the firmware and ramdisk via the standard
request_firmware(..) interface, copies the contents to card memory and
interrupts the card BIOS to initiate boot.
Thanks,
Sudeep Dutt
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Dutt <sudeep.dutt@intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Rusty Russell <rusty@rustcorp.com.au>,
"Michael S. Tsirkin" <mst@redhat.com>,
Rob Landley <rob@landley.net>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-doc@vger.kernel.org, Asias He <asias@redhat.com>,
Nikhil Rao <nikhil.rao@intel.com>,
Ashutosh Dixit <ashutosh.dixit@intel.com>,
Caz Yokoyama <Caz.Yokoyama@intel.com>,
Dasaratharaman Chandramouli
<dasaratharaman.chandramouli@intel.com>,
Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>,
"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
Sudeep Dutt <sudeep.dutt@intel.com>
Subject: Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
Date: Fri, 06 Sep 2013 11:41:03 -0700 [thread overview]
Message-ID: <1378492863.107744.69.camel@localhost> (raw)
In-Reply-To: <20130906050157.GF28806@kroah.com>
On Thu, 2013-09-05 at 22:01 -0700, Greg Kroah-Hartman wrote:
> On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote:
> > +What: /sys/class/mic/mic(x)/firmware
> > +Date: August 2013
> > +KernelVersion: 3.11
> > +Contact: Sudeep Dutt <sudeep.dutt@intel.com>
> > +Description:
> > + When read, this sysfs entry provides the path name under
> > + /lib/firmware/ where the firmware image to be booted on the
> > + card can be found. The entry can be written to change the
> > + firmware image location under /lib/firmware/.
>
> I don't understand, is the path under the HOST device, or the Client
> device's disk? Why do you need to change the path on the HOST? What's
> wrong with the existing firmware path selection we have in the kernel?
>
The path is on the host. The card does not have a physical persistent
disk device. Our customers like the flexibility of changing the card
firmware/ramdisk contents and file names for individual MIC cards. This
flexibility is not possible with a static set of firmware file names in
the kernel for all cards.
Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs,
card boot is initiated via the "state" sysfs entry. The host driver then
obtains the contents of the firmware and ramdisk via the standard
request_firmware(..) interface, copies the contents to card memory and
interrupts the card BIOS to initiate boot.
Thanks,
Sudeep Dutt
next prev parent reply other threads:[~2013-09-06 18:41 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-05 23:41 [PATCH RESEND v3 0/7] Enable Drivers for Intel MIC X100 Coprocessors Sudeep Dutt
2013-09-05 23:41 ` Sudeep Dutt
2013-09-05 23:41 ` [PATCH RESEND v3 1/7] Intel MIC Host Driver for X100 family Sudeep Dutt
2013-09-05 23:41 ` Sudeep Dutt
2013-09-06 4:55 ` Greg Kroah-Hartman
2013-09-06 4:55 ` Greg Kroah-Hartman
2013-09-06 4:57 ` Greg Kroah-Hartman
2013-09-06 4:57 ` Greg Kroah-Hartman
2013-09-05 23:41 ` [PATCH RESEND v3 2/7] Intel MIC Host Driver Interrupt/SMPT support Sudeep Dutt
2013-09-05 23:41 ` Sudeep Dutt
2013-09-05 23:41 ` [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management Sudeep Dutt
2013-09-05 23:41 ` Sudeep Dutt
2013-09-06 4:58 ` Greg Kroah-Hartman
2013-09-06 4:58 ` Greg Kroah-Hartman
2013-09-06 18:29 ` Sudeep Dutt
2013-09-06 18:29 ` Sudeep Dutt
2013-09-06 18:41 ` Greg Kroah-Hartman
2013-09-06 18:41 ` Greg Kroah-Hartman
2013-09-06 5:00 ` Greg Kroah-Hartman
2013-09-06 5:00 ` Greg Kroah-Hartman
2013-09-06 18:30 ` Sudeep Dutt
2013-09-06 18:30 ` Sudeep Dutt
2013-09-06 5:01 ` Greg Kroah-Hartman
2013-09-06 5:01 ` Greg Kroah-Hartman
2013-09-06 18:41 ` Sudeep Dutt [this message]
2013-09-06 18:41 ` Sudeep Dutt
2013-09-06 19:04 ` Greg Kroah-Hartman
2013-09-06 19:04 ` Greg Kroah-Hartman
2013-09-06 22:00 ` Sudeep Dutt
2013-09-06 22:00 ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 4/7] Intel MIC Card Driver for X100 family Sudeep Dutt
2013-09-05 23:42 ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 5/7] Intel MIC Host Driver Changes for Virtio Devices Sudeep Dutt
2013-09-05 23:42 ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 6/7] Intel MIC Card " Sudeep Dutt
2013-09-05 23:42 ` Sudeep Dutt
2013-09-05 23:42 ` [PATCH RESEND v3 7/7] Sample Implementation of Intel MIC User Space Daemon Sudeep Dutt
2013-09-05 23:42 ` Sudeep Dutt
2013-09-06 1:36 ` [PATCH RESEND v3 0/7] Enable Drivers for Intel MIC X100 Coprocessors Joe Perches
2013-09-06 1:36 ` Joe Perches
2013-09-06 18:27 ` Sudeep Dutt
2013-09-06 18:27 ` Sudeep Dutt
2013-09-26 20:54 ` Greg Kroah-Hartman
2013-09-26 20:54 ` Greg Kroah-Hartman
2013-09-26 21:33 ` Joe Perches
2013-09-26 21:33 ` Joe Perches
2013-09-26 21:40 ` Sudeep Dutt
2013-09-26 21:40 ` Sudeep Dutt
2013-09-26 20:53 ` Greg Kroah-Hartman
2013-09-26 20:53 ` Greg Kroah-Hartman
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=1378492863.107744.69.camel@localhost \
--to=sudeep.dutt@intel.com \
--cc=Caz.Yokoyama@intel.com \
--cc=arnd@arndb.de \
--cc=ashutosh.dixit@intel.com \
--cc=dasaratharaman.chandramouli@intel.com \
--cc=eddie.dong@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=harshavardhan.r.kharche@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=rob@landley.net \
--cc=virtualization@lists.linux-foundation.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.