> >> > 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
> > +static const struct auxiliary_device_id intel_dg_spi_id_table[] = {
> > + {
> > + .name = "i915.spi",
> > + },
> > + {
> > + .name = "xe.spi",
> > + },
> > + {
> > + /* sentinel */
> > + }
> > +};
> > +MODULE_DEVICE_TABLE(auxiliary, intel_dg_spi_id_tab
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Friday, March 29, 2024 15:47
> To: Usyskin, Alexander ; Miquel Raynal
> ; Richard Weinberger ; Vignesh
> Raghavendra ; Jani Nikula ;
> Joonas Lahtinen ; Vivi, Rodrigo
>
> Cc: Lubart, Vitaly ; linux-...@li
Hi Miquel
Intel Gfx in infinite wisdom decided to create another driver - Xe and
the spi driver part of this series should be moved to some common location.
Should it be drivers/mtd or drivers/spi, or some other place?
--
Thanks,
Sasha
>
> Hi Alexander,
>
> + Michael and Tudor
>
> Folks, a
>
> > > > > > + spi->mtd.writesize = SZ_1; /* 1 byte granularity */
> > > > >
> > > > > You say writesize should be aligned with 4 in your next patch?
> > > >
> > > > We support unaligned write by reading aligned 4bytes,
> > > > replacing changed bytes there and writing whole 4bytes back.
> > >
> > > > + spi->mtd.writesize = SZ_1; /* 1 byte granularity */
> > >
> > > You say writesize should be aligned with 4 in your next patch?
> >
> > We support unaligned write by reading aligned 4bytes,
> > replacing changed bytes there and writing whole 4bytes back.
> > Is there any problem with
Hi Miquel,
> > +static int i915_spi_init_mtd(struct i915_spi *spi, struct device *device,
> > +unsigned int nparts)
> > +{
> > + unsigned int i;
> > + unsigned int n;
> > + struct mtd_partition *parts = NULL;
> > + int ret;
> > +
> > + dev_dbg(device, "registerin
> >
> > > There is a Discreet Graphic device with embedded SPI (controller & flash).
> > > The embedded SPI is not visible to OS.
> > > There is another HW in the chip that gates access to the controller and
> > > exposes registers for:
> > > region select; read and write (4 and 8 bytes); erase (4K
>
> > > This sounds like there's some sort of MFD rather than or as well as a
> > > flash
> > > chip, or possibly multiple SPI devices?
>
> > Yes, the driver doesn't talk to SPI controller directly it goes via
> > another layer, so all SPI standard HW is not accessible, but we wish
> > to expose
> > > > No SPI controllers are directly visible to userspace, some SPI devices
> > > > are selectively exposed but that needs to be explicitly requested and is
> > > > generally discouraged.
>
> > > What are the options here? Explicitly request exception is the one.
> > > Any other way to add acce
>
> > The spi controller on discreet graphics card is not visible to user-space.
> > Spi access flows are supported by another hardware module and relevant
> registers are
> > available on graphics device memory bar.
>
> No SPI controllers are directly visible to userspace, some SPI devices
> are
ows are supported by another hardware module and relevant
registers are
available on graphics device memory bar.
Auxiliary bus device is created to separate spi code and flows from already
overloaded i915 driver.
--
Thanks,
Sasha
> > This series is intended to be upstreamed through drm tree.
>
> On Sun, 10 Sep 2023, Alexander Usyskin
> wrote:
> > From: Jani Nikula
>
> I'm almost certain I did not write this patch originally. The authorship
> may have been changed accidentally along the way, but it's not mine.
>
> BR,
> Jani.
>
Sorry for that, seems like some rebase flux in the inte
> > 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
> > When driver wakes up the firmware from the low power state, it is sending
> > a memory ready message.
> > The send is done via synchronous/blocking function to ensure that
> firmware
> > is in ready state. However, in case of firmware undergoing reset send
> > might be block forever.
> > To add
> > diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
> > index 71fbf0bc8453..3174cad8a5cc 100644
> > --- a/drivers/misc/mei/bus-fixup.c
> > +++ b/drivers/misc/mei/bus-fixup.c
> > @@ -128,7 +128,7 @@ static int mei_osver(struct mei_cl_device *cldev)
> > os_ver = (struct m
> > >
> > > It looks to me that we need to move the gsc out of the intel_gt instead of
> > > workaround the initialization.
> >
> > The interrupts are handled by gt, so where this should go ?
> >
>
> Ouch, I've seen it now. But still this patch brings me more doubts...
>
> is gsc really a per-gt
> > +static void pxp_is_ready(struct mei_cl_device *cldev)
> > +{
> > + struct mei_device *bus = cldev->bus;
> > +
> > + switch (bus->pxp_mode) {
> > + case MEI_DEV_PXP_READY:
> > + case MEI_DEV_PXP_DEFAULT:
> > + cldev->do_match = 1;
>
> Can you explain why you set do_match = 1
> Subject: [PATCH v2 00/14] GSC support for XeHP SDV and DG2 platforms
>
> Add GSC support for XeHP SDV and DG2 platforms.
>
> The series includes changes for the mei driver:
> - add ability to use polling instead of interrupts
> - add ability to use extended timeouts
> - setup extended operation
: Tuesday, March 22, 2022 22:10
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; Tvrtko
> Ursulin
> Cc: linux-ker...@vger.kernel.org; Winkler, Tomas
> ; Lubart, Vitaly ; intel-
> g...@l
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Thursday, March 10, 2022 21:04
> To: Usyskin, Alexander
> Cc: Greg Kroah-Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; David Airlie ; Daniel
> Vetter ; Tvrtko Ursulin ;
> linux-ker...@vger.kernel.org; Winkle
> -Original Message-
> From: Ceraolo Spurio, Daniele
> Sent: Thursday, March 10, 2022 02:28
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; Tvrtko
> Ursulin
> Cc
> -Original Message-
> From: Ceraolo Spurio, Daniele
> Sent: Thursday, March 10, 2022 02:24
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; Tvrtko
> Ursulin
> Cc
> -Original Message-
> From: Ceraolo Spurio, Daniele
> Sent: Thursday, March 10, 2022 00:50
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; Tvrtko
> Ursulin
> Cc: i
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, February 17, 2022 11:38
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter
> Cc: Winkler, Tomas ; L
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, February 17, 2022 11:26
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter
> Cc: linux-ker...@vger.kernel.org
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Wednesday, February 16, 2022 14:04
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter
> Cc: linux-ker...@vger.kernel.org
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Tuesday, February 15, 2022 14:30
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter
> Cc: linux-ker...@vger.kernel.org
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Sunday, February 13, 2022 11:56
> To: Usyskin, Alexander
> Cc: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; Winkler,
> Tomas ; Lubart, Vitaly ;
> intel-gfx@lists
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Wednesday, January 26, 2022 20:06
> To: Usyskin, Alexander
> Cc: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; Winkler,
> Tomas ; Lubart, Vitaly ;
> intel-gfx@lists
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, July 23, 2019 14:29
> To: Winkler, Tomas ; intel-
> g...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org; Usyskin, Alexander
> ; C, Ramalingam
> Subject: RE: [PAT
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-de...@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-de...@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-gfx@lists.freedesktop.org; dri-de...@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-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
> jani.nik...@linux.intel.com; Winkler, Tomas ;
&g
55 matches
Mail list logo
