On Thu, 1 Apr 2021 21:46:22 +0530
Manivannan Sadhasivam wrote:
> On Thu, Apr 01, 2021 at 05:54:21PM +0200, Boris Brezillon wrote:
> > On Thu, 1 Apr 2021 20:49:54 +0530
> > Manivannan Sadhasivam wrote:
> >
> > > @@ -565,6 +608,11 @@ static int nand_bl
On Thu, 1 Apr 2021 15:48:12 +0530
Manivannan Sadhasivam wrote:
> static int nand_isbad_bbm(struct nand_chip *chip, loff_t ofs)
> {
> + struct mtd_info *mtd = nand_to_mtd(chip);
> + int last_page = ((mtd->erasesize - mtd->writesize) >>
> +chip->page_shift) &
On Thu, 1 Apr 2021 20:49:54 +0530
Manivannan Sadhasivam wrote:
> @@ -565,6 +608,11 @@ static int nand_block_isreserved(struct mtd_info *mtd,
> loff_t ofs)
>
> if (!chip->bbt)
> return 0;
> +
> + /* Check if the region is secured */
> + if
On Fri, 19 Mar 2021 20:30:10 +0530
Manivannan Sadhasivam wrote:
> @@ -2737,6 +2783,11 @@ static int nand_read_page_swecc(struct nand_chip
> *chip, uint8_t *buf,
> uint8_t *ecc_code = chip->ecc.code_buf;
> unsigned int max_bitflips = 0;
>
> + /* Check if the region is secured
On Fri, 19 Mar 2021 20:30:10 +0530
Manivannan Sadhasivam wrote:
> On a typical end product, a vendor may choose to secure some regions in
> the NAND memory which are supposed to stay intact between FW upgrades.
> The access to those regions will be blocked by a secure element like
> Trustzone.
On Wed, 17 Mar 2021 19:22:49 +0530
Manivannan Sadhasivam wrote:
> On Wed, Mar 17, 2021 at 02:14:49PM +0100, Boris Brezillon wrote:
> > On Wed, 17 Mar 2021 17:55:13 +0530
> > Manivannan Sadhasivam wrote:
> >
> > > On a typical end product, a vendor may
On Wed, 17 Mar 2021 17:55:13 +0530
Manivannan Sadhasivam wrote:
> On a typical end product, a vendor may choose to secure some regions in
> the NAND memory which are supposed to stay intact between FW upgrades.
> The access to those regions will be blocked by a secure element like
> Trustzone.
On Mon, 8 Mar 2021 19:01:34 +0530
Manivannan Sadhasivam wrote:
> On Mon, Mar 08, 2021 at 10:10:59AM +0100, Boris Brezillon wrote:
> > On Mon, 8 Mar 2021 11:14:46 +0530
> > Manivannan Sadhasivam wrote:
> >
> > > On a typical end product, a vendor may
On Mon, 8 Mar 2021 11:14:46 +0530
Manivannan Sadhasivam wrote:
> On a typical end product, a vendor may choose to secure some regions in
> the NAND memory which are supposed to stay intact between FW upgrades.
> The access to those regions will be blocked by a secure element like
> Trustzone.
On Mon, 8 Mar 2021 11:14:47 +0530
Manivannan Sadhasivam wrote:
> On a typical end product, a vendor may choose to secure some regions in
> the NAND memory which are supposed to stay intact between FW upgrades.
> The access to those regions will be blocked by a secure element like
> Trustzone.
On Thu, 4 Feb 2021 10:04:08 +0100
Miquel Raynal wrote:
> Hi Boris,
>
> Boris Brezillon wrote on Thu, 4 Feb
> 2021 09:59:45 +0100:
>
> > On Thu, 4 Feb 2021 14:22:21 +0530
> > Manivannan Sadhasivam wrote:
> >
> > > On Thu, Feb 04, 202
On Thu, 4 Feb 2021 14:22:21 +0530
Manivannan Sadhasivam wrote:
> On Thu, Feb 04, 2021 at 09:13:36AM +0100, Miquel Raynal wrote:
> > Hi Manivannan,
> >
> > Manivannan Sadhasivam wrote on Wed,
> > 03 Feb 2021 17:11:31 +0530:
> >
> > > On 3 Feb
On Wed, 03 Feb 2021 16:22:42 +0530
Manivannan Sadhasivam wrote:
> On 3 February 2021 3:49:14 PM IST, Boris Brezillon
> wrote:
> >On Wed, 03 Feb 2021 15:42:02 +0530
> >Manivannan Sadhasivam wrote:
> >
> >> >>
> >> >> I got more informat
On Wed, 03 Feb 2021 15:42:02 +0530
Manivannan Sadhasivam wrote:
> >>
> >> I got more information from the vendor, Telit. The access to the 3rd
> >partition is protected by Trustzone and any access in non privileged
> >mode (where Linux kernel runs) causes kernel panic and the device
>
s/staging/media/rkvdec/rkvdec.c
> >
> >966
> > > 967 static const struct of_device_id of_rkvdec_match[] = {
> >968 { .compatible = "rockchip,rk3399-vdec" },
> >969 { /* sentinel */ }
> >97
+Alexandre, the new I3C maintainer. You should probably flag him as the
person to contact if you have problem with the I3C tree in the future.
Hi Stephen,
On Sun, 3 Jan 2021 22:32:17 +1100
Stephen Rothwell wrote:
> Hi all,
>
> Fetching the i3c-fixes tree
>
Boris Brezillon (1):
i3c: Resign from my maintainer role
Colin Ian King (1):
i3c/master: Fix uninitialized variable next_addr
Nicolas Pitre (3):
dt-bindings: i3c: MIPI I3C Host Controller Interface
i3c/master: introduce the mipi-i3c-hci driver
i3c
On Thu, 17 Dec 2020 12:28:44 -0800
Sowjanya Komatineni wrote:
> Tegra Quad SPI controller hardware supports sending dummy bytes based
> on programmed dummy clock cycles after the actual transfer bytes.
>
> This patch adds this support of hardware dummy bytes transfer and
> skips transfer of
On Fri, 18 Dec 2020 14:51:08 +0530
Pratyush Yadav wrote:
> Hi Sowjanya,
>
> On 17/12/20 12:28PM, Sowjanya Komatineni wrote:
> > This patch marks dummy transfer by setting dummy_data bit to 1.
> >
> > Controllers supporting dummy transfer by hardware use this bit field
> > to skip software
On Sun, 13 Dec 2020 10:54:26 +0100
Boris Brezillon wrote:
> On Sat, 12 Dec 2020 09:28:50 -0800
> Sowjanya Komatineni wrote:
>
> > On 12/12/20 2:57 AM, Boris Brezillon wrote:
> > > On Fri, 11 Dec 2020 13:15:59 -0800
> > > Sowjanya Komatineni wrote:
> &
On Fri, 11 Dec 2020 13:16:00 -0800
Sowjanya Komatineni wrote:
> Tegra Quad SPI controller hardware supports sending dummy cycles
> after address bytes.
>
> This patch adds this support.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/spi/spi-tegra210-quad.c | 22 +-
On Sat, 12 Dec 2020 09:28:50 -0800
Sowjanya Komatineni wrote:
> On 12/12/20 2:57 AM, Boris Brezillon wrote:
> > On Fri, 11 Dec 2020 13:15:59 -0800
> > Sowjanya Komatineni wrote:
> >
> >> This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controll
On Fri, 11 Dec 2020 13:15:59 -0800
Sowjanya Komatineni wrote:
> This patch adds a flag SPI_MASTER_USES_HW_DUMMY_CYCLES for the controllers
> that support transfer of dummy cycles by the hardware directly.
Hm, not sure this is a good idea. I mean, if we expect regular SPI
devices to use this
On Fri, 20 Nov 2020 12:23:59 +0100
Miquel Raynal wrote:
> Hi Serge,
>
> Stephen Rothwell wrote on Fri, 20 Nov 2020
> 11:39:29 +1100:
>
> > Hi all,
> >
> > After merging the nand tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> >
> >
On Fri, 6 Nov 2020 22:28:38 +0800
Thirumalesha Narasimhappa wrote:
> The MT29F2G01AAAED is a single die, 2Gb Micron SPI NAND Flash with 4-bit
> ECC
>
> Signed-off-by: Thirumalesha Narasimhappa
> ---
>
> v6: Reverted the SPINAND_OP_VARIANTS() as they were in v4 for
> MT29F2G01AAAED device
>
+Tudor and Vignesh
On Fri, 6 Nov 2020 10:21:06 +
Chin-Ting Kuo wrote:
> Hi Boris,
>
> Thanks for your comments and suggestions.
>
> > -Original Message-----
> > From: Boris Brezillon
> > Sent: Friday, November 6, 2020 5:06 PM
> > To: Chin-Tin
On Fri, 6 Nov 2020 08:58:23 +
Chin-Ting Kuo wrote:
> Hi Boris,
>
> Thanks for your quick reply.
>
> > -Original Message-----
> > From: Boris Brezillon
> > Sent: Thursday, November 5, 2020 11:12 PM
> > To: Cédric Le Goater ; robh...@kernel.org
> &
Hi,
On Thu, 5 Nov 2020 15:09:11 +0100
Cédric Le Goater wrote:
> Hello Chin-Ting,
>
> Thanks for this driver. It's much cleaner than the previous and we should
> try adding support for the AST2500 SoC also. I guess we can keep the old
> driver for the AST2400 which has a different register
On Tue, 3 Nov 2020 23:18:54 +0800
Thirumalesha N wrote:
> Hi Boris,
>
> On Tue, Nov 3, 2020 at 11:03 PM Boris Brezillon <
> boris.brezil...@collabora.com> wrote:
>
> > On Tue, 3 Nov 2020 22:59:01 +0800
> > Thirumalesha Narasimhappa wrote:
> >
> &
On Tue, 3 Nov 2020 22:59:01 +0800
Thirumalesha Narasimhappa wrote:
> The MT29F2G01AAAED is a single die, 2Gb Micron SPI NAND Flash with 4-bit
> ECC
>
> Signed-off-by: Thirumalesha Narasimhappa
> ---
>
> v5: As per the review comments, the changes were reverted to the v2,
> except the
On Fri, 30 Oct 2020 14:58:33 +
Steven Price wrote:
> When unloading the call to pm_runtime_put_sync_suspend() will attempt to
> turn the GPU cores off, however panfrost_device_fini() will have turned
> the clocks off. This leads to the hardware locking up.
>
> Instead don't call
Hi Stephen,
On Mon, 2 Nov 2020 12:46:37 +1100
Stephen Rothwell wrote:
> Hi all,
>
> After merging the imx-drm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_close':
>
the drm node.
>
> Move the initialisation/destruction to panfrost_job_{init,fini} where it
> belongs.
>
Queued to drm-misc-next.
Thanks,
Boris
> Fixes: 1a11a88cfd9a ("drm/panfrost: Fix job timeout handling")
> Signed-off-by: Steven Price
> Reviewed-by: Boris B
Hello,
On Sat, 10 Oct 2020 11:01:39 +0530
Md Sadre Alam wrote:
> This change will add initial support for qspi (serial nand).
>
> QPIC Version v.2.0 onwards supports serial nand as well so this
> change will initialize all required register to enable qspi (serial
> nand).
>
> This change is
On Thu, 29 Oct 2020 08:53:44 +0100
Miquel Raynal wrote:
> Hello,
>
> mda...@codeaurora.org wrote on Wed, 28 Oct 2020 23:54:23 +0530:
>
> > On 2020-10-28 15:18, Miquel Raynal wrote:
> > > Hello,
> > >
> > > Md Sadre Alam wrote on Sat, 10 Oct 2020
> > > 11:01:37 +0530:
> > >
> > >> QPIC
Hello Linus,
I'm a bit late, but here is the I3C PR for 5.10.
Regards,
Boris
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the Git repository at:
On Fri, 11 Sep 2020 11:33:50 +0800
Jing Xiangfeng wrote:
> Fix to return negative error code -ENOMEM from the error handling
> case instead of 0.
>
> Signed-off-by: Jing Xiangfeng
Queued to i3c/next.
Thanks,
Boris
> ---
> drivers/i3c/master/i3c-master-cdns.c | 4 +++-
> 1 file changed, 3
On Mon, 28 Sep 2020 18:21:59 +0200
Miquel Raynal wrote:
> Hi Boris,
>
> Boris Brezillon wrote on Mon, 28 Sep
> 2020 18:03:43 +0200:
>
> > On Mon, 28 Sep 2020 17:50:05 +0200
> > Miquel Raynal wrote:
> >
> > > > > The way OOB
> > > &g
On Mon, 28 Sep 2020 17:50:05 +0200
Miquel Raynal wrote:
> > > The way OOB
> > > bytes are organized do not seem relevant to me, I think i prefer the
> > > "_4_/_8_" naming,even if it's not very explicit.
> >
> > The ECC strength doesn't say anything about the scheme used for ECC
> > bytes
On Mon, 28 Sep 2020 16:55:28 +0200
Miquel Raynal wrote:
> > IMHO, grouped means, ecc bytes are at continuous address, where as
> > interleaved means ecc bytes splitted into multiple addresses
>
> I don't like the name. Interleaved means that there are OOB bytes
> stored in the data section,
On Tue, 25 Aug 2020 08:31:49 +0200
Parshuram Thombare wrote:
> This patch fix following issue.
> Controller slots blocked for devices with static_addr
> but no init_dyn_addr may limit the number of I3C devices
> on the bus which gets dynamic address in DAA. So
> instead of attaching all the
On Mon, 24 Aug 2020 17:14:56 +0530
Vignesh Raghavendra wrote:
> Hi Jan,
>
> On 8/24/20 11:25 AM, Jan Kiszka wrote:
> [...]
>
> >> +MODULE_AUTHOR("Vignesh Raghavendra ");
> >>
> > On the AM65x, this changes mtd->name (thus mtd-id for
> > parser/cmdlinepart) from 4704.spi.0 to spi7.0. The
On Sun, 23 Aug 2020 19:14:10 +0800
Thirumalesha Narasimhappa wrote:
> The MT29F2G01AAAED is a single die, 2Gb Micron SPI NAND Flash with 4-bit
> ECC
>
> Signed-off-by: Thirumalesha Narasimhappa
> ---
> v2: removed SPINAND_SELECT_TARGET as per the comments & fixed typo errors
>
>
On Sun, 23 Aug 2020 11:59:18 +0200
Boris Brezillon wrote:
> > -static void i3c_master_pre_assign_dyn_addr(struct i3c_dev_desc *dev)
> > +static int i3c_master_early_i3c_dev_add(struct i3c_master_controller
> > *master,
> > +
On Fri, 21 Aug 2020 11:13:15 +0200
Parshuram Thombare wrote:
> This patch fix following issue.
> Controller slots blocked for devices with static_addr
> but no init_dyn_addr may limit the number of I3C devices
> on the bus which gets dynamic address in DAA. So
> instead of attaching all the
On Thu, 20 Aug 2020 21:03:11 +0200
Boris Brezillon wrote:
> On Thu, 20 Aug 2020 18:16:14 +
> Parshuram Raju Thombare wrote:
>
> > >Hm, not sure that qualifies as a fix. The current implementation was
> > >correct, it was just reserving a slot in t
On Thu, 20 Aug 2020 18:16:14 +
Parshuram Raju Thombare wrote:
> >Hm, not sure that qualifies as a fix. The current implementation was
> >correct, it was just reserving a slot in the device table for devices
> >that didn't have an init address or on which SETDASA failed.
> If I3C
On Thu, 20 Aug 2020 15:38:26 +0200
Parshuram Thombare wrote:
> This patch fix following issue.
> Controller slots blocked for devices with static_addr
> but no init_dyn_addr may limit the number of I3C devices
> on the bus which gets dynamic address in DAA. So
> instead of attaching all the
On Thu, 20 Aug 2020 09:23:25 +
Parshuram Raju Thombare wrote:
> Hi Boris,
>
> Thanks for your comments.
>
> >> + * We anyway don't attach devices which are not addressable
> >
> >You can drop the anyway.
> Sure, I will make above mentioned change in the comment.
>
> >> + * (no
On Wed, 12 Aug 2020 16:13:11 +0200
Miquel Raynal wrote:
> +
> +#define SVC_I3C_MAX_DEVS 32
> +
> +struct svc_i3c_cmd {
> + u8 addr;
> + bool rnw;
> + u8 *in;
> + const void *out;
> + unsigned int len;
> + unsigned int read_len;
> + bool continued;
> +};
> +
> +struct
Hello Parshuram,
Sorry for the late reply :-/.
On Thu, 21 May 2020 11:33:01 +0200
Parshuram Thombare wrote:
> This patch fix following issue.
> Controller slots blocked for devices with static_addr
> but no init_dyn_addr may limit the number of I3C devices
> on the bus which gets dynamic
VIDIOC_TRY_EXT_FMT, struct v4l2_ext_pix_format *argp);
>
> The only valid types are V4L2_BUF_TYPE_VIDEO_CAPTURE and
> V4L2_BUF_TYPE_VIDEO_OUTPUT,
> all the other types are invalid with this API.
>
[...]
>
>
> Boris Brezillon (5):
> media: v4l2: Extend pix
On Fri, 10 Jul 2020 08:50:28 -0300
Ezequiel Garcia wrote:
> On Fri, 2020-07-10 at 10:13 +0200, Boris Brezillon wrote:
> > On Fri, 10 Jul 2020 01:21:07 -0300
> > Ezequiel Garcia wrote:
> >
> > > Hello Jonas,
> > >
> > > In the context of t
On Fri, 10 Jul 2020 01:21:07 -0300
Ezequiel Garcia wrote:
> Hello Jonas,
>
> In the context of the uAPI cleanup,
> I'm revisiting this patch.
>
> On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> > Add DPB entry flags to help indicate when a reference frame is a field
> > picture
> >
On Mon, 18 May 2020 19:39:08 +0200
Enric Balletbo i Serra wrote:
> Convert mtk_dpi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chun-Kuang Hu
> ---
>
>
On Mon, 18 May 2020 19:39:09 +0200
Enric Balletbo i Serra wrote:
> The mtk_dpi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chun-Kuang Hu
> ---
>
>
On Wed, 1 Jul 2020 13:23:03 +0200
Boris Brezillon wrote:
> On Mon, 18 May 2020 19:39:07 +0200
> Enric Balletbo i Serra wrote:
>
> > This is really a cosmetic change just to make a bit more readable the
> > code after convert the driver to drm_bridge. The bridge variable
On Mon, 18 May 2020 19:39:07 +0200
Enric Balletbo i Serra wrote:
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named
On Thu, 18 Jun 2020 15:23:45 +0100
Guillaume Tucker wrote:
> On 18/06/2020 15:09, Miquel Raynal wrote:
> > Hi Guillaume,
> >
> > Miquel Raynal wrote on Thu, 18 Jun 2020
> > 15:23:24 +0200:
> >
> >> Hi Guillaume,
> >>
> >> Guillaume Tucker wrote on Thu, 18 Jun
> >> 2020 13:28:05 +0100:
> >>
On Tue, 02 Jun 2020 10:59:46 +0200
Bean Huo wrote:
> On Tue, 2020-06-02 at 09:48 +0200, Boris Brezillon wrote:
> > Hi Bean,
> >
> > On Mon, 01 Jun 2020 23:10:43 +0200
> > Bean Huo wrote:
> >
> > > Hi Richard
> > > would you please
Hi Bean,
On Mon, 01 Jun 2020 23:10:43 +0200
Bean Huo wrote:
> Hi Richard
> would you please help us confirm below question??
Miquel suggested an approach that would allow us to deal with both JFFS2
and UBI/UBIFS without having any FS/wear-leveling specific code at the
NAND level, but you
Hello Linus,
On Mon, 1 Jun 2020 11:39:05 -0700
Linus Torvalds wrote:
> On Mon, Jun 1, 2020 at 12:54 AM Boris Brezillon
> wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git i3c/for-5.8
>
> Hmm. No such ref..
>
> I see the "i3c/ne
Hello Linus,
Here is the I3C PR for 5.8.
Regards,
Boris
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git i3c/for-5.8
On Thu, 21 May 2020 11:32:22 +0200
Parshuram Thombare wrote:
> Boardinfo was lost if I3C object for devices with boardinfo
> available are not created or not added to the I3C device list
> because of some failure e.g. SETDASA failed, retrieve info failed etc
> This patch adds
On Thu, 28 May 2020 15:58:02 +0800
Mason Yang wrote:
> Hello,
>
> JESD216C has defined specification for Octal 8S-8S-8S and 8D-8D-8D.
> Based on JEDEC216C Basic Flash Parameter Table (BFPT) driver extract
> DWORD-18: command and command extension type.
> DWORD-20: Maximum operation speed of
On Sat, 23 May 2020 04:10:25 +0530
Pratyush Yadav wrote:
> diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> index 69491f3a515d..4e4292f0ee1d 100644
> --- a/drivers/spi/spi-mxic.c
> +++ b/drivers/spi/spi-mxic.c
> @@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem
On Fri, 22 May 2020 15:42:43 +0530
Pratyush Yadav wrote:
> In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
> the "command extension". There can be 3 types of extensions in xSPI:
> repeat, invert, and hex. When the extension type is "repeat", the same
> opcode is sent
On Fri, 22 May 2020 01:33:15 +0530
Pratyush Yadav wrote:
> On 22/05/20 01:11AM, Pratyush Yadav wrote:
> > On 21/05/20 08:22PM, Boris Brezillon wrote:
> > > On Wed, 20 May 2020 22:00:38 +0530
> > > Pratyush Yadav wrote:
> > >
> > > > In xSPI
On Wed, 20 May 2020 22:00:38 +0530
Pratyush Yadav wrote:
> In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
> the "command extension". There can be 3 types of extensions in xSPI:
> repeat, invert, and hex. When the extension type is "repeat", the same
> opcode is sent
On Thu, 14 May 2020 18:30:09 +0200
Parshuram Thombare wrote:
> This patch fix following issues.
> 1. Controller slots blocked for devices with static_addr
>but no init_dyn_addr may limit the number of I3C devices
>on the bus which gets dynamic address in DAA. So
>instead of attaching
las 18:29, Miquel Raynal
> > > escribió:
> > >
> > > Hello,
> > >
> > > Boris Brezillon wrote on Mon, 4 May
> > > 2020 12:32:37 +0200:
> > >
> > >> On Mon, 4 May 2020 11:42:53 +0200
> > >> Álvaro Fe
On Tue, 12 May 2020 05:03:32 +
Parshuram Raju Thombare wrote:
> >> Document describing secondary master initialization,
> >> mastership handover and DEFSLVS handling processes.
> >
> >Thanks for doing that, but you probably didn't try to compile the doc
> >(the formatting is all messed
On Mon, 11 May 2020 15:14:49 +0200
Parshuram Thombare wrote:
> Added mastership acquire and yield functions.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/i3c/master.c | 187 +++--
> include/linux/i3c/master.h | 23 +
> 2 files changed, 201
On Mon, 11 May 2020 15:13:53 +0200
Parshuram Thombare wrote:
> add i3c_secondary_master_register which is used
> to register secondary masters.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/i3c/master.c | 154 -
> include/linux/i3c/master.h |
On Mon, 11 May 2020 15:12:39 +0200
Parshuram Thombare wrote:
> Document describing secondary master initialization,
> mastership handover and DEFSLVS handling processes.
Thanks for doing that, but you probably didn't try to compile the doc
(the formatting is all messed up).
# make htmldocs
On Mon, 11 May 2020 15:13:05 +0200
Parshuram Thombare wrote:
> Removed last argument 'secondary' and refactored
> i3c_master_register to move code that can be common
> to i3c_secondary_master_register to separate function
> i3c_master_init.
>
> Signed-off-by: Parshuram Thombare
> ---
>
On Mon, 11 May 2020 09:00:35 +
wrote:
> Hi, Pratyush, Boris,
>
> On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote:
> > This series adds support for octal DTR flashes in the spi-nor framework,
>
> I'm still learning about this, but I can give you my 2 cents as of now, to
>
On Thu, 7 May 2020 14:38:52 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
>Thank you very much for the review comments and your time...
>
> On 7/5/2020 2:27 pm, Boris Brezillon wrote:
> > On Thu, 7 May 2020 14:13:42 +0800
> > &quo
On Thu, 7 May 2020 14:13:42 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
> Thank you very much for the review comments and your time...
>
> On 7/5/2020 1:28 pm, Boris Brezillon wrote:
> > On Thu, 7 May 2020 08:15:37 +0800
> > &qu
On Thu, 7 May 2020 08:15:37 +0800
"Ramuthevar,Vadivel MuruganX"
wrote:
> + reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num));
> + writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN,
> +ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num));
Seriously, did you really
On Tue, 5 May 2020 11:44:43 +0200
Boris Brezillon wrote:
> On Tue, 5 May 2020 17:31:45 +0800
> masonccy...@mxic.com.tw wrote:
>
>
> > > > > > I quickly went through your patches but can't reply them in each
> > > > > >
> > you
On Tue, 5 May 2020 17:31:45 +0800
masonccy...@mxic.com.tw wrote:
> > > > > I quickly went through your patches but can't reply them in each
> your
> > > > > patches.
> > > > >
> > > > > i.e,.
> > > > > 1) [v4,03/16] spi: spi-mem: allow specifying a command's extension
> > > > >
> > > > > -
Hello Vadivel,
On Tue, 5 May 2020 13:28:58 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> >>
> >> ebu_nand: ebu_nand@e0f0 {
> >> compatible = "intel,lgm-ebu-nand";
> >> reg = <0xe0f0 0x100
> >>
On Mon, 04 May 2020 14:38:23 -0400
Nicolas Dufresne wrote:
> Le lundi 04 mai 2020 à 14:01 -0400, Nicolas Dufresne a écrit :
> > Le samedi 02 mai 2020 à 19:55 -0300, Ezequiel Garcia a écrit :
> > > +Nicolas
> > >
> > > On Sat, 2020-05-02 at 20:37 +0200, Bor
On Mon, 04 May 2020 14:01:32 -0400
Nicolas Dufresne wrote:
> Le samedi 02 mai 2020 à 19:55 -0300, Ezequiel Garcia a écrit :
> > +Nicolas
> >
> > On Sat, 2020-05-02 at 20:37 +0200, Boris Brezillon wrote:
> > > On Fri, 01 May 2020 13:57:49 -030
On Mon, 4 May 2020 11:42:53 +0200
Álvaro Fernández Rojas wrote:
> Some NAND controllers change the ECC bytes when OOB is written with ECC
> enabled.
> This is a problem in brcmnand, since adding JFFS2 cleanmarkers after the page
> has been erased will change the ECC bytes to 0 and the
On Mon, 4 May 2020 16:50:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
> On 4/5/2020 3:17 pm, Boris Brezillon wrote:
> > On Mon, 4 May 2020 15:15:08 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > wrote:
> >
> >> Hi
On Mon, 4 May 2020 15:15:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
>Thank you very much for the prompt review and suggestions...
>
> On 4/5/2020 3:08 pm, Boris Brezillon wrote:
> > On Mon, 4 May 2020 10:02:35 +0800
> > "
On Mon, 4 May 2020 10:02:35 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
> On 30/4/2020 9:01 pm, Boris Brezillon wrote:
> > On Thu, 30 Apr 2020 14:36:00 +0200
> > Boris Brezillon wrote:
> >
> >> On Thu, 30 Apr 2020 17:07:03 +0800
&
On Fri, 01 May 2020 13:57:49 -0300
Ezequiel Garcia wrote:
> > > +
> > > +.. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
> > > +
> > > +.. flat-table:: enum v4l2_vp9_reset_frame_context
> > > +:header-rows: 0
> > > +:stub-columns: 0
> > > +:widths: 1 2
> > > +
> > > +* -
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
> On Thu, 30 Apr 2020 17:07:03 +0800
> "Ramuthevar, Vadivel MuruganX"
> wrote:
>
> > >>> The question is, is it the same value we have in nand_pa or it is
> > >>> different?
> >
On Thu, 30 Apr 2020 14:26:51 +0200
Ricardo Ribalda Delgado wrote:
> Hi
>
> On Mon, Apr 27, 2020 at 9:10 PM Boris Brezillon
> wrote:
> >
> > On Mon, 27 Apr 2020 16:49:22 +0200
> > Miquel Raynal wrote:
> >
> > > Hi Boris,
> > >
> >
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> >>> The question is, is it the same value we have in nand_pa or it is
> >>> different?
> >>>
> >> Different address which is 0xE140 NAND_BASE_PHY address.
> >
> > Then why didn't you tell me they didn't match
On Thu, 30 Apr 2020 16:30:15 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> >>>
> >>> And now I'd like you to explain why 5 is the right value for that field
> >>> (I guess that has to do with the position of the CS/ALE/CLE pins).
> >>
> >> 5 : bit 26, 25, 24, 23, 22 to be included for
On Thu, 30 Apr 2020 15:50:30 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
>Thank you very much for keep reviewing the patches and more queries...
>
> On 29/4/2020 11:31 pm, Boris Brezillon wrote:
> > On Wed, 29 Apr 2020 23:18:31 +0800
&g
On Fri, 17 Apr 2020 18:21:02 +0200
Parshuram Thombare wrote:
> +
> +/* This function is expected to be called with normaluse_lock */
> +int i3c_master_acquire_bus(struct i3c_master_controller *master)
> +{
> + int ret = 0;
> +
> + if (!master->this || master->this !=
On Fri, 17 Apr 2020 18:20:52 +0200
Parshuram Thombare wrote:
> To support mastership handover procedure, this patch splits the
> bus_init callback into bus_init and master_set_info callbacks
Missing period at the end of this sentence.
IIRC, we discussed passing master info directly at
On Fri, 17 Apr 2020 18:20:42 +0200
Parshuram Thombare wrote:
> Flow diagram for I3C mastership handover, DEFSLVS
> processing and secondary master initialization.
>
Thanks for doing that, that's really appreciated, but the document
doesn't seem to be formatted properly. Would you mind fixing
On Wed, 29 Apr 2020 18:42:04 +0800
"Ramuthevar,Vadivel MuruganX"
wrote:
> From: Ramuthevar Vadivel Murugan
>
> Add YAML file for dt-bindings to support NAND Flash Controller
> on Intel's Lightning Mountain SoC.
>
> Signed-off-by: Ramuthevar Vadivel Murugan
>
> ---
>
On Wed, 29 Apr 2020 23:18:31 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
> Hi Boris,
>
> On 29/4/2020 10:48 pm, Boris Brezillon wrote:
> > On Wed, 29 Apr 2020 22:33:37 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > wrote:
> >
> >&
1 - 100 of 10969 matches
Mail list logo
