> Subject: Re: [PATCH 2/9] mei: late_bind: add late binding component driver
>
> On Wed, Jul 16, 2025 at 02:26:26PM +, Usyskin, Alexander wrote:
> > > > > > + if (bytes < sizeof(rsp)) {
> > > > > > + dev_err(dev, "bad res
> Subject: Re: [PATCH 2/9] mei: late_bind: add late binding component driver
>
> On Wed, Jul 16, 2025 at 11:58:19AM +, Usyskin, Alexander wrote:
> > > Subject: Re: [PATCH 2/9] mei: late_bind: add late binding component driver
> > >
> > > On Thu, Jul 10, 20
> Subject: Re: [PATCH 2/9] mei: late_bind: add late binding component driver
>
> On Thu, Jul 10, 2025 at 11:08:33AM -0400, Rodrigo Vivi wrote:
> > From: Alexander Usyskin
> >
> > Introduce a new MEI client driver to support Late Binding firmware
> > upload/update for Intel discrete graphics platf
> Subject: Re: [PATCH v7 2/9] mei: late_bind: add late binding component driver
>
> On Tue, Jul 08, 2025 at 12:42:30AM +0530, Badal Nilawar wrote:
> > From: Alexander Usyskin
> >
> > Add late binding component driver.
>
> That says what this does, but not why, or even what "late binding"
> means
> Subject: Re: [PATCH v4 02/10] mei: late_bind: add late binding component
> driver
>
> On Tue, Jul 01, 2025 at 10:11:54PM +0530, Nilawar, Badal wrote:
> >
> > On 01-07-2025 18:04, Nilawar, Badal wrote:
> > >
> > > On 01-07-2025 15:15, Greg KH wrote:
> > > > On Tue, Jul 01, 2025 at 02:02:15PM +053
> -Original Message-
> From: Greg KH
> Sent: Saturday, June 28, 2025 3:18 PM
> To: Nilawar, Badal
> Cc: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; Gupta, Anshuman ;
> Vivi, Rodrigo ; Usyskin, Alexander
> ;
But then who uses it? And why? Normally forcing callers to set .owner
> is
> > frowned apon, use a #define correctly to have it automatically set for you
> > in
> > the registration function please.
> >
> > And are you _sure_ you need it?
>
> In xe
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> - Ursprüngliche Mail -
> > Von: "Alexander Usyskin"
> > In general, it is fine for me - we have parent mtd initialized and
> > participating
> > in power management.
> >
> > I can't see how to bend idr_alloc to al
> Subject: Re: [PATCH v2 05/10] drm/xe/xe_late_bind_fw: Load late binding
> firmware
>
>
>
> On 6/6/2025 10:57 AM, Badal Nilawar wrote:
> > Load late binding firmware
> >
> > v2:
> > - s/EAGAIN/EBUSY/
> > - Flush worker in suspend and driver unload (Daniele)
> >
> > Signed-off-by: Badal Nila
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> Hello,
>
> On 11/06/2025 at 10:52:36 GMT, "Usyskin, Alexander"
> wrote:
>
> >> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
> >>
> >>
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> - Ursprüngliche Mail -
> > Von: "Miquel Raynal"
> >> On 6/10/25 05:54, Richard Weinberger wrote:
> >>> - Ursprüngliche Mail -
> Von: "Alexander Usyskin"
> Richard, I've reproduced your setup (mod
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> - Ursprüngliche Mail -
> > Von: "Guenter Roeck"
> >>> I am trying to boot from "pnor". It looks like the partition data (from
> >>> devicetree)
> >>> is now ignored. mtdblock6 used to be the second flash.
> >>>
> >
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> On 6/9/25 05:23, Usyskin, Alexander wrote:
> >> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
> >>
> >>
> >>>>>> Several of my qemu boot
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
>
> Several of my qemu boot tests fail to boot from mtd devices with this
> patch
> in the mainline kernel. Reverting it fixes the problem. As far as I can
> see this affects configurations with
> CONFIG_MTD_P
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> Hi,
>
> On Sun, Mar 02, 2025 at 04:09:11PM +0200, Alexander Usyskin wrote:
> > Create master device without partition when
> > CONFIG_MTD_PARTITIONED_MASTER flag is unset.
> >
> > This streamlines device tree and allows t
> Subject: Re: [PATCH v11 08/10] drm/xe/nvm: add on-die non-volatile
> memory device
>
> Hey,
>
> I was looking into testing this with the xe code on PVC, and noticed some
> small
> changes that would be useful to integrate before merging.
>
> On 2025-05-28 15:51, Alexander Usyskin wrote:
> > E
> Subject: Re: [PATCH v10 06/10] drm/i915/nvm: add nvm device for discrete
> graphics
>
> On Tue, May 27, 2025 at 11:30:20AM +0530, Usyskin, Alexander wrote:
> > > Subject: Re: [PATCH v10 06/10] drm/i915/nvm: add nvm device for discrete
> > > graphics
> > &
> Subject: Re: [PATCH v10 08/10] drm/xe/nvm: add on-die non-volatile
> memory device
>
> On Tue, May 27, 2025 at 11:55:13AM +0530, Usyskin, Alexander wrote:
> > > Subject: Re: [PATCH v10 08/10] drm/xe/nvm: add on-die non-volatile
> > > memory device
> > >
&
> Subject: Re: [PATCH v10 08/10] drm/xe/nvm: add on-die non-volatile
> memory device
>
> On Thu, May 15, 2025 at 04:33:43PM +0300, Alexander Usyskin wrote:
> > Enable access to internal non-volatile memory on DGFX
> > with GSC/CSC devices via a child device.
> > The nvm child device is exposed via
> Subject: Re: [PATCH v10 05/10] mtd: intel-dg: align 64bit read and write
>
> On Thu, May 15, 2025 at 04:33:40PM +0300, Alexander Usyskin wrote:
> > GSC NVM controller HW errors on quad access overlapping 1K border.
> > Align 64bit read and write to avoid readq/writeq over 1K border.
> >
> > Acke
> Subject: Re: [PATCH v10 06/10] drm/i915/nvm: add nvm device for discrete
> graphics
>
> On Thu, May 15, 2025 at 04:33:41PM +0300, Alexander Usyskin wrote:
> > Enable access to internal non-volatile memory on
> > DGFX devices via a child device.
> > The nvm child device is exposed via auxiliary b
> Subject: Re: [PATCH v10 04/10] mtd: intel-dg: register with mtd
>
> On Thu, May 15, 2025 at 04:33:39PM +0300, Alexander Usyskin wrote:
> > Register the on-die nvm device with the mtd subsystem.
> > Refcount nvm object on _get and _put mtd callbacks.
> > For erase operation address and size shoul
> Subject: Re: [PATCH v10 03/10] mtd: intel-dg: implement access functions
>
> On Thu, May 15, 2025 at 04:33:38PM +0300, Alexander Usyskin wrote:
> > Implement read(), erase() and write() functions.
>
> ...
>
> > +__maybe_unused
> > +static ssize_t idg_write(struct intel_dg_nvm *nvm, u8 region,
> Subject: Re: [PATCH v10 03/10] mtd: intel-dg: implement access functions
>
> On Thu, May 15, 2025 at 04:33:38PM +0300, Alexander Usyskin wrote:
> > Implement read(), erase() and write() functions.
>
> ...
>
> > +__maybe_unused
> > +static unsigned int idg_nvm_get_region(const struct intel_dg_n
> Subject: Re: [PATCH v9 03/12] mtd: intel-dg: implement region enumeration
>
> On Thu, May 15, 2025 at 04:53:38PM +0530, Usyskin, Alexander wrote:
> > > On Thu, Apr 24, 2025 at 04:25:27PM +0300, Alexander Usyskin wrote:
> > > > In intel-dg, there is no access to t
> Subject: Re: [PATCH v9 03/12] mtd: intel-dg: implement region enumeration
>
> On Thu, Apr 24, 2025 at 04:25:27PM +0300, Alexander Usyskin wrote:
> > In intel-dg, there is no access to the spi controller,
> > the information is extracted from the descriptor region.
>
> ...
>
> > @@ -22,9 +24,19
> Subject: Re: [PATCH v9 02/12] mtd: add driver for intel graphics non-volatile
> memory device
>
> On Thu, Apr 24, 2025 at 04:25:26PM +0300, Alexander Usyskin wrote:
> > Add auxiliary driver for intel discrete graphics
> > non-volatile memory device.
>
> ...
>
> > +static int intel_dg_mtd_probe
>
>
> > diff --git a/include/drm/intel/xe_late_bind_mei_interface.h
> b/include/drm/intel/xe_late_bind_mei_interface.h
> > new file mode 100644
> > index ..4005c4c6184f
> > --- /dev/null
> > +++ b/include/drm/intel/xe_late_bind_mei_interface.h
> > @@ -0,0 +1,49 @@
> > +/* SPDX-License
>
> On 26/03/2025 at 17:26:12 +02, Alexander Usyskin
> wrote:
>
> > Create master device without partition when
> > CONFIG_MTD_PARTITIONED_MASTER flag is unset.
> >
> > This streamlines device tree and allows to anchor
> > runtime power management on master device in all cases.
> >
> > Signed-of
> Subject: RE: [PATCH v7 01/12] mtd: core: always create master device
>
> Hi
>
> > Hello,
> >
> > > The mtd_master is completely different class to avoid mtd tree
> disturbances.
> > > It is real kernel device object, I'm not sure how we can do 'link to'
> > > magic here.
> >
> > Maybe we can ad
Hi
> Hello,
>
> > The mtd_master is completely different class to avoid mtd tree disturbances.
> > It is real kernel device object, I'm not sure how we can do 'link to'
> > magic here.
>
> Maybe we can add that later if someone needs.
>
> > About MTD_PARTITIONED_MASTER - we can treat it as ano
> On Wed, Mar 26, 2025 at 05:26:11PM +0200, Alexander Usyskin wrote:
> > Add driver for access to Intel discrete graphics card
> > internal NVM device.
> > Expose device on auxiliary bus by i915 and Xe drivers and
> > provide mtd driver to register this device with MTD framework.
> >
> > This is a
> On 26/03/2025 at 17:26:12 +02, Alexander Usyskin
> wrote:
>
> > Create master device without partition when
> > CONFIG_MTD_PARTITIONED_MASTER flag is unset.
> >
> > This streamlines device tree and allows to anchor
> > runtime power management on master device in all cases.
> >
> > Signed-off-b
> > Add driver for access to Intel discrete graphics card
> > internal NVM device.
> > Expose device on auxiliary bus by i915 and Xe drivers and
> > provide mtd driver to register this device with MTD framework.
> >
> > This is a rewrite of "drm/i915/spi: spi access for discrete graphics"
> > and "
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, January 29, 2025 11:51 PM
> To: Usyskin, Alexander
> Cc: Miquel Raynal ; Richard Weinberger
> ; Vignesh Raghavendra ; De Marchi,
> Lucas ; Thomas Hellström
> ; Maarten Lankhorst
> ; Maxime R
> >> > This streamlines device tree and allows to anchor
> >> > runtime power management on master device in all cases.
> >>
> >> Please explain in more detail why this is needed.
> >> If this change makes the overall situation better and breaks
> >> no userspace, I'm happy. :-)
> >>
> >
> > The re
> > Create master device without partition when
> > CONFIG_MTD_PARTITIONED_MASTER flag is unset.
> >
> > This streamlines device tree and allows to anchor
> > runtime power management on master device in all cases.
>
> Please explain in more detail why this is needed.
> If this change makes the ov
> > > Create master device without partition when
> > > CONFIG_MTD_PARTITIONED_MASTER flag is unset.
> >
> > I don't think you took into consideration my remarks regarding the fact
> > that you would break userspace. If you enable the master, you no longer
> > have the same device numbering in user
> Subject: Re: [PATCH v4 01/11] mtd: core: always create master device
>
> Hi Alexander,
>
> On 01/01/2025 at 17:39:15 +02, Alexander Usyskin
> wrote:
>
> > Create master device without partition when
> > CONFIG_MTD_PARTITIONED_MASTER flag is unset.
>
> I don't think you took into consideratio
> > GSC NVM controller HW errors on quad access overlapping 1K border.
> > Align 64bit read and write to avoid readq/writeq over 1K border.
> >
> > Acked-by: Miquel Raynal
> > Signed-off-by: Alexander Usyskin
> > ---
> > drivers/mtd/devices/mtd-intel-dg.c | 35
> ++
>
> ...
>
> > +struct intel_dg_nvm {
> > + struct kref refcnt;
> > + void __iomem *base;
> > + size_t size;
> > + unsigned int nregions;
> > + struct {
> > + const char *name;
> > + u8 id;
> > + u64 offset;
> > + u64 size;
> > + } regions[];
>
> _
>
> > @@ -89,6 +281,13 @@ static int intel_dg_mtd_probe(struct
> auxiliary_device *aux_dev,
> > goto err;
> > }
> >
> > + ret = intel_dg_nvm_init(nvm, device);
> > + if (ret < 0) {
> > + dev_err(device, "cannot initialize nvm\n");
> > + ret = -ENODEV;
>
> W
> >>
> >> >> If so, I have to add patch for mtd subsystem to always have device for
> >> master
> >> >> initialized regardless of kernel flag.
> >> >> Only to initialize struct device, not to create full mtd node.
> >> >>
> >> >> Miquel - are you agree to this?
> >>
> >> Conceptually yes, but pleas
>
> Hello Alexander,
>
> >> If so, I have to add patch for mtd subsystem to always have device for
> master
> >> initialized regardless of kernel flag.
> >> Only to initialize struct device, not to create full mtd node.
> >>
> >> Miquel - are you agree to this?
>
> Conceptually yes, but please m
> > +
> > +static ssize_t idg_nvm_rewrite_partial(struct intel_dg_nvm *nvm, loff_t to,
> > + loff_t offset, size_t len, const u32
> *newdata)
> > +{
> > + u32 data = idg_nvm_read32(nvm, to);
> > +
> > + if (idg_nvm_error(nvm))
> > + return -EIO;
> > +
> > >> @@ -474,20 +478,28 @@ static int intel_dg_mtd_erase(struct mtd_info
> > *mtd, struct erase_info *info)
> > >> total_len = info->len;
> > >> addr = info->addr;
> > >>
> > >> +ret = pm_runtime_resume_and_get(mtd->dev.parent);
> > > on this, I really don't believe this
> >> @@ -474,20 +478,28 @@ static int intel_dg_mtd_erase(struct mtd_info
> *mtd, struct erase_info *info)
> >>total_len = info->len;
> >>addr = info->addr;
> >>
> >> + ret = pm_runtime_resume_and_get(mtd->dev.parent);
> > on this, I really don't believe this is right and we should use
> >
Adding Kartihik
> Subject: Re: [PATCH 06/10] mtd: intel-dg: wake card on operations
>
> Hi Alexander,
>
> Please reduce the context when answering, otherwise it's hard to find
> all places where you commented.
>
> >> > > > That's the part that I'm not sure if I agree. if I remember from some
>
> -Original Message-
> From: Usyskin, Alexander
> Sent: Sunday, November 10, 2024 3:17 PM
> To: Vivi, Rodrigo
> Cc: Gupta, Anshuman ; Deak, Imre
> ; Miquel Raynal ;
> Richard Weinberger ; Vignesh Raghavendra
> ; De Marchi, Lucas ; Thomas
> Hellström ; Maarten
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Friday, November 8, 2024 12:50 AM
> To: Usyskin, Alexander
> Cc: Gupta, Anshuman ; Deak, Imre
> ; Miquel Raynal ;
> Richard Weinberger ; Vignesh Raghavendra
> ; De Marchi, Lucas ; Thomas
> Hellström ; Maarten
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Monday, November 4, 2024 11:16 PM
> To: Usyskin, Alexander
> Cc: Gupta, Anshuman ; Deak, Imre
> ; Miquel Raynal ;
> Richard Weinberger ; Vignesh Raghavendra
> ; De Marchi, Lucas ; Thomas
> Hellström ; Maarten
> -Original Message-
> From: Gupta, Anshuman
> Sent: Monday, October 28, 2024 5:02 PM
> To: Vivi, Rodrigo ; Usyskin, Alexander
> ; Deak, Imre
> Cc: Miquel Raynal ; Richard Weinberger
> ; Vignesh Raghavendra ; De Marchi,
> Lucas ; Thomas Hellström
> ; Maarten
> On Sat, Sep 21, 2024 at 01:00:52PM +, Winkler, Tomas wrote:
> > > On Thu, Sep 19, 2024 at 09:54:24AM +, Winkler, Tomas wrote:
> > > > > On Mon, Sep 16, 2024 at 04:49:17PM +0300, Alexander Usyskin
> wrote:
>
> > > Just do normal open coded allocations, the reference counting is just
> > >
> Subject: Re: [PATCH v6 08/12] drm/i915/spi: add spi device for discrete
> graphics
>
> On Mon, 16 Sep 2024, Alexander Usyskin
> wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> > index 39f6614a0a99..b9d4f9be5355 100644
> > --- a/drivers/gpu/drm/i915/
> On Mon, Sep 16, 2024 at 04:49:16PM +0300, Alexander Usyskin wrote:
> > Add driver for access to Intel discrete graphics card
> > internal SPI device.
> > Expose device on auxiliary bus by i915 and Xe drivers and
> > provide spi driver to register this device with MTD framework.
>
> As far as I c
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > index d50354bfb993..bef6d7f8ac55 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > @@ -127,6 +127,10 @@ static int i915_pxp_tee_c
l.com; Winkler, Tomas ;
> Usyskin, Alexander
> Cc: Vivi, Rodrigo
> Subject: Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP
> Pairing info
>
>
>
> On Wednesday 09 May 2018 03:58 PM, Shankar, Uma wrote:
> >
> >> -Origi
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, May 16, 2018 18:20
> To: Usyskin, Alexander ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@lin
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, May 16, 2018 16:05
> To: Usyskin, Alexander ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@lin
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, April 03, 2018 16:57
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler,
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, April 03, 2018 16:57
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
&g
61 matches
Mail list logo
