Hi Conor, Thanks for the feedback. > Subject: Re: [RFC PATCH 1/2] riscv: vendors: andes: Add support to > configure the PMA regions > > On 08/09/2022 09:39, Biju Das wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know > > the content is safe > > > > Hi Conor, Atish, > > > > What RISC-V devices you have? > > A bunch ;) > > A __couple__ PolarFire SoC boards, HiFive Unleashed, D1 Nezha, Canaan > k210 MAIX something & the VisionFive. If standard DMA api works without any issue means, on these platforms IO Coherence port is enabled in the hardware. So all peripherals involving DMA work as expected. > > Ours is RISC-V uniprocessor without IO Coherence Port. > > What does "IO Coherence Port" mean? Zicbo*? The HW will provide coherency between CPU and peripheral. If Zibco* is uniprocessor, then highly it may not have IO coherence Port enabled in their design. Guo, Please confirm. > > > Currently USB, ethernet, SDHI/eMMC doesn't work with standard DMA > > api's. > > Sounds pretty similar to the D1 so. > > > On RISC-V world, how do we handle DMA api for uniprocessor without IO > > Coherence Port? > > If you do mean Zicbo* you're into errata territory there & I don't know > if that'll be acceptable upstream - not for me to make that call... It is not errata for sure. It is a HW design where we don't have IO cache coherency port enabled in the HW. So looks like it is not an extension or errata but it is core stuff. Something similar to incoherency mentioned in below [1] for uniprocessor Systems. [1] https://elinux.org/images/8/80/Initializing-riscv.pdf 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: > >>> > >>> 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: > >>> > >>> 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. > >
