Hi Conor, Atish, What RISC-V devices you have? Ours is RISC-V uniprocessor without IO Coherence Port. Currently USB, ethernet, SDHI/eMMC doesn't work with standard DMA api's. On RISC-V world, how do we handle DMA api for uniprocessor without IO Coherence Port? Cheers, Biju > -----Original Message----- > From: Conor.Dooley@xxxxxxxxxxxxx <Conor.Dooley@xxxxxxxxxxxxx> > Sent: 08 September 2022 00:38 > To: atishp@xxxxxxxxxxxxxx > Cc: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>; > paul.walmsley@xxxxxxxxxx; palmer@xxxxxxxxxxx; aou@xxxxxxxxxxxxxxxxx; > atishp@xxxxxxxxxxxx; apatel@xxxxxxxxxxxxxxxx; geert+renesas@xxxxxxxxx; > linux-riscv@xxxxxxxxxxxxxxxxxxx; linux-renesas-soc@xxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; prabhakar.csengg@xxxxxxxxx; Biju Das > <biju.das.jz@xxxxxxxxxxxxxx> > Subject: Re: [RFC PATCH 1/2] riscv: vendors: andes: Add support to > configure the PMA regions > > On 07/09/2022 22:52, Atish Patra wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know > > the content is safe > > > > > > On Tue, Sep 6, 2022 at 3:40 AM <Conor.Dooley@xxxxxxxxxxxxx > > <mailto:Conor.Dooley@xxxxxxxxxxxxx>> wrote: > > > > On 06/09/2022 11:21, Lad Prabhakar wrote: > > > >> diff --git a/arch/riscv/include/asm/sbi.h > >> b/arch/riscv/include/asm/sbi.h index 2a0ef738695e..10a7c855d125 > >> 100644 --- a/arch/riscv/include/asm/sbi.h +++ > >> b/arch/riscv/include/asm/sbi.h @@ -37,6 +37,7 @@ enum sbi_ext_id { > >> > >> /* Vendor extensions must lie within this range */ > >> SBI_EXT_VENDOR_START = 0x09000000, + SBI_EXT_ANDES = > >> 0x0900031E, SBI_EXT_VENDOR_END = 0x09FFFFFF, }; > > > > Everything else aside, I am very interested in what's happening here. > > I'll take a proper look through things later, but for now: > > > > For PolarFire SoC we have an InterHart Communication SBI EXT that > > would would like to upstream support for. We are not aiming to put the > > driver itself in arch/riscv - it's just a mailbox driver, but I would > > like to use sbi.h for defining the vendor id etc. > > > > I am not sure how this all aligns with: > >> We'll only accept patches for new modules or extensions if the > >> specifications for those modules or extensions are listed as being > >> "Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of > >> course, maintain their own Linux kernel trees that contain code for > >> any draft extensions that they wish.) > >> > >> Additionally, the RISC-V specification allows implementors to create > >> their own custom extensions. These custom extensions aren't required > >> to go through any review or ratification process by the RISC-V > >> Foundation. To avoid the maintenance complexity and potential > >> performance impact of adding kernel code for implementor-specific > >> RISC-V extensions, we'll only to accept patches for extensions that > >> have been officially frozen or ratified by the RISC-V Foundation. > >> (Implementors, may, of course, maintain their own Linux kernel trees > >> containing code for any custom extensions that they wish.) > > > > Which is in: > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > > .kernel.org%2Friscv%2Fpatch-acceptance.html&data=05%7C01%7Cbiju.da > > s.jz%40bp.renesas.com%7C7fd3275accdb450e547a08da912a0042%7C53d82571da1 > > 947e49cb4625a166a4a2a%7C0%7C0%7C637981906834865446%7CUnknown%7CTWFpbGZ > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > > D%7C3000%7C%7C%7C&sdata=YAV2Ahz7TFMJJ3wCj%2FAdDuDEcPq0kXXL%2B3o6FA > > d0%2BUI%3D&reserved=0 > > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc > > s.kernel.org%2Friscv%2Fpatch-acceptance.html&data=05%7C01%7Cbiju.d > > as.jz%40bp.renesas.com%7C7fd3275accdb450e547a08da912a0042%7C53d82571da > > 1947e49cb4625a166a4a2a%7C0%7C0%7C637981906834865446%7CUnknown%7CTWFpbG > > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% > > 3D%7C3000%7C%7C%7C&sdata=YAV2Ahz7TFMJJ3wCj%2FAdDuDEcPq0kXXL%2B3o6F > > Ad0%2BUI%3D&reserved=0> > > > > It is unclear to me whether that is just for ISA extensions or if that > > covers SBI extensions too. At least for us, since we don't touch arch > > code there is relatively little friction & there's no concerns about > > reducing the portability of a kernel since it is just a regular old > > driver. > > > > > > It covers the standard SBI extensions as well. However, I don't think > > this includes a vendor extension as there is no freeze or ratification > > associated with vendor extensions. > > > > It would be good to discuss the policy around vendor SBI extensions > > during LPC as well. We also need to discuss the ACPI policy as well. > > We most likely need a BoF to discuss these adhoc topics. I will check > > if we can schedule a BoF in advance. > > I did briefly mention this to Palmer on IRC last night, just was busy > today & didn't get a chance to reply here. The indication there was that > yes, this paragraph did cover SBI extensions - which would make vendor > extensions not permitted upstream. > > We (microchip) are "only" doing a few ecalls in a driver but this seems a > fair bit more intrusive since it is in arch code. Even if the answer is a > "no" - a no from the horses mouth rather than on IRC & maybe some > rewording of that doc to be clearer would be nice. > > I'd be down for a BoF, even if just to get a "no" in person haha > > Conor. > > > > > I was planning on cornering some people *cough* Palmer *cough* at LPC > > and asking him what his thoughts were there. > > > > FWIW this is what we have been doing: > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > ub.com%2Flinux4microchip%2Flinux%2Fblob%2Flinux-5.15-mchp%2Fdrivers%2F > > mailbox%2Fmailbox-miv-ihc.c%23L27&data=05%7C01%7Cbiju.das.jz%40bp. > > renesas.com%7C7fd3275accdb450e547a08da912a0042%7C53d82571da1947e49cb46 > > 25a166a4a2a%7C0%7C0%7C637981906834865446%7CUnknown%7CTWFpbGZsb3d8eyJWI > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > > C%7C%7C&sdata=seNiuv6EsY1u0SIT33%2F0CWHJu401d5zSaNmVb%2BUHKPM%3D&a > > mp;reserved=0 > > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > hub.com%2Flinux4microchip%2Flinux%2Fblob%2Flinux-5.15-mchp%2Fdrivers%2 > > Fmailbox%2Fmailbox-miv-ihc.c%23L27&data=05%7C01%7Cbiju.das.jz%40bp > > .renesas.com%7C7fd3275accdb450e547a08da912a0042%7C53d82571da1947e49cb4 > > 625a166a4a2a%7C0%7C0%7C637981906834865446%7CUnknown%7CTWFpbGZsb3d8eyJW > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% > > 7C%7C%7C&sdata=seNiuv6EsY1u0SIT33%2F0CWHJu401d5zSaNmVb%2BUHKPM%3D& > > amp;reserved=0> > > > > The IP itself has not stabilised yet, so we have not sent any patches > > yet, but we do intend doing so... > > > > But yea, I'll take a properly look at what you're doing here soonTM, > > although at this point it may be the other side of LPC. > > > > btw, where can I get my hands on your hardware? > > > > Thanks, Conor. > > > > > > _______________________________________________ linux-riscv mailing > > list linux-riscv@xxxxxxxxxxxxxxxxxxx > > <mailto:linux-riscv@xxxxxxxxxxxxxxxxxxx> > > https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists > > .infradead.org%2Fmailman%2Flistinfo%2Flinux-riscv&data=05%7C01%7Cb > > iju.das.jz%40bp.renesas.com%7C7fd3275accdb450e547a08da912a0042%7C53d82 > > 571da1947e49cb4625a166a4a2a%7C0%7C0%7C637981906834865446%7CUnknown%7CT > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > > 6Mn0%3D%7C3000%7C%7C%7C&sdata=AaMGs%2BqRpuw8MOWci3qPvJ1W5U296Vp%2B > > higFxDSoHmo%3D&reserved=0 > > <https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > > s.infradead.org%2Fmailman%2Flistinfo%2Flinux-riscv&data=05%7C01%7C > > biju.das.jz%40bp.renesas.com%7C7fd3275accdb450e547a08da912a0042%7C53d8 > > 2571da1947e49cb4625a166a4a2a%7C0%7C0%7C637981906834865446%7CUnknown%7C > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > > I6Mn0%3D%7C3000%7C%7C%7C&sdata=AaMGs%2BqRpuw8MOWci3qPvJ1W5U296Vp%2 > > BhigFxDSoHmo%3D&reserved=0> > > > > > > > > -- Regards, Atish
