| Message ID | cb7022c9-0059-4eb2-7910-aab42124fa1c@cogentembedded.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add Renesas RPC-IF support | expand |
Hello Sergei, On Tue, Dec 10, 2019, Sergei Shtylyov wrote: > Here's a set of 2 patches against Linus' repo. Renesas Reduced Pin Count > Interface (RPC-IF) allows a SPI flash or HyperFlash connected to the SoC to > be accessed via the external address space read mode or the manual mode. Looking at this driver, all it is are APIs. Meaning another driver is needed to sit in between the MTD layer and this HW driver layer. In the driver that I did, if the "RPC" HW is going to be used to control a SPI Flash device, it registered a spi controller and then the MTD layer could access the device just like any other SPI controller driver. No additional drivers are needed. Looking at the hyperbus driver that is in drivers/mtd/hyperbus/, it seems that if the "RPC" HW is going to be used to control HyperFlash, then all you would need to do is register a hyperbus controller using hyperbus_register_device(). Then the MTD layer could read/write the flash using normal MTD CFI interface. Why do you think you need another layer in between the HW driver and the MTD layer? Is your goal to make a multi-layered system where the HW jumps back and forth in between operating modes at runtime? I'm not sure of the use case for all of this. Chris
HEllo On 12/11/2019 05:33 PM, Chris Brandt wrote: >> Here's a set of 2 patches against Linus' repo. Renesas Reduced Pin Count >> Interface (RPC-IF) allows a SPI flash or HyperFlash connected to the SoC to >> be accessed via the external address space read mode or the manual mode. > > Looking at this driver, all it is are APIs. Meaning another driver is > needed to sit in between the MTD layer and this HW driver layer. Between the hardware and SPI, and between the hardware and HyperFlash infrastructure. There's a lot of the common hardware code common between these 2 driver areas. > In the driver that I did, if the "RPC" HW is going to be used to control > a SPI Flash device, it registered a spi controller and then the MTD > layer could access the device just like any other SPI controller driver. No > additional drivers are needed. We're already been thru that with Mason's patch -- I don't want the code duplicated between 2 drivers. > Looking at the hyperbus driver that is in drivers/mtd/hyperbus/, it > seems that if the "RPC" HW is going to be used to control HyperFlash, then Sure. But the code controlling RPC hardware is largely the same b/w 2 cases. > all you would need to do is register a hyperbus controller using > hyperbus_register_device(). Then the MTD layer could read/write the flash using > normal MTD CFI interface. That's what I do (the current realization makes too many assumptions about the HF hardware (both direct read and write). > Why do you think you need another layer in between the HW driver and the > MTD layer? Because we don't want any duplicated code. Also, think about DT -- it describes the hardware, not the driver configuration. > Is your goal to make a multi-layered system where the HW jumps back and forth > in between operating modes at runtime? I'm not sure of the use case for all of > this. My goal is to prevent the code duplication (and keep DT sane too). > Chris MBR, Sergei
On 12/11/2019 05:33 PM, Chris Brandt wrote: >> Here's a set of 2 patches against Linus' repo. Renesas Reduced Pin Count >> Interface (RPC-IF) allows a SPI flash or HyperFlash connected to the SoC to >> be accessed via the external address space read mode or the manual mode. > > Looking at this driver, all it is are APIs. Meaning another driver is > needed to sit in between the MTD layer and this HW driver layer. > > In the driver that I did, if the "RPC" HW is going to be used to control > a SPI Flash device, it registered a spi controller and then the MTD > layer could access the device Via the SPI-to-MTD sublayer for (at least) direct mapping -- grep for "dirmap" in drivers/mtd/spi-nor/spi-nor.c... > just like any other SPI controller driver. No > additional drivers are needed. Then why do we have *struct* spi_controller_mem_ops? Do All drivers implement such ops? [...] MBR, Sergei