| Message ID | 20190625075746.10439-4-vigneshr@ti.com |
|---|---|
| State | Accepted |
| Delegated to: | Miquel Raynal |
| Headers | show |
| Series | MTD: Add Initial Hyperbus support | expand |
Hello! On 06/25/2019 10:57 AM, Vignesh Raghavendra wrote: > Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate > Bus interface between a host system master and one or more slave > interfaces. HyperBus is used to connect microprocessor, microcontroller, > or ASIC devices with random access NOR flash memory (called HyperFlash) > or self refresh DRAM (called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in HyperBus > specification[1]. > > HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since HyperBus is x8 DDR bus, > its equivalent to x16 parallel NOR flash with respect to bits per clock > cycle. But HyperBus operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > > But, HyperBus memory controllers seem to abstract implementation details > and expose a simple MMIO interface to access connected flash. > > Add support for registering HyperFlash devices with MTD framework. MTD > maps framework along with CFI chip support framework are used to support > communicating with flash. > > Framework is modelled along the lines of spi-nor framework. HyperBus > memory controller (HBMC) drivers calls hyperbus_register_device() to > register a single HyperFlash device. HyperFlash core parses MMIO access > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > Some HBMC masters need calibration/training sequence[3] to be carried > out, in order for DLL inside the controller to lock, by reading a known > string/pattern. This is done by repeatedly reading CFI Query > Identification String. Calibration needs to be done before trying to detect > flash as part of CFI flash probe. > > HyperRAM is not supported at the moment. > > HyperBus specification can be found at[1] > HyperFlash datasheet can be found at[2] > > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > index 806287e80e84..62d649a959e2 100644 > --- a/drivers/mtd/Makefile > +++ b/drivers/mtd/Makefile > @@ -34,3 +34,4 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/ > > obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/ > obj-$(CONFIG_MTD_UBI) += ubi/ > +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus/ > diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig > new file mode 100644 > index 000000000000..98147e28caa0 > --- /dev/null > +++ b/drivers/mtd/hyperbus/Kconfig > @@ -0,0 +1,11 @@ > +menuconfig MTD_HYPERBUS > + tristate "HyperBus support" > + select MTD_CFI > + select MTD_MAP_BANK_WIDTH_2 > + select MTD_CFI_AMDSTD > + select MTD_COMPLEX_MAPPINGS > + help > + This is the framework for the HyperBus which can be used by > + the HyperBus Controller driver to communicate with > + HyperFlash. See Cypress HyperBus specification for more > + details > diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile > new file mode 100644 > index 000000000000..ca61dedd730d > --- /dev/null > +++ b/drivers/mtd/hyperbus/Makefile > @@ -0,0 +1,3 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o > diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c > new file mode 100644 > index 000000000000..63a9e64895bc > --- /dev/null > +++ b/drivers/mtd/hyperbus/hyperbus-core.c > @@ -0,0 +1,154 @@ [...] > +int hyperbus_register_device(struct hyperbus_device *hbdev) > +{ [...] > + hbdev->mtd = do_map_probe("cfi_probe", map); > + if (!hbdev->mtd) { > + dev_err(dev, "probing of hyperbus device failed\n"); > + return -ENODEV; > + } > + > + hbdev->mtd->dev.parent = dev; > + mtd_set_of_node(hbdev->mtd, np); > + > + ret = mtd_device_register(hbdev->mtd, NULL, 0); > + if (ret) { > + dev_err(dev, "failed to register mtd device\n"); > + map_destroy(hbdev->mtd); > + return ret; > + } > + hbdev->registered = true; I doubt that you actually need this flag... > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(hyperbus_register_device); > + > +int hyperbus_unregister_device(struct hyperbus_device *hbdev) > +{ > + int ret = 0; > + > + if (hbdev && hbdev->mtd && hbdev->registered) { ... as you missed clearing that 'registered' flag. > + ret = mtd_device_unregister(hbdev->mtd); > + map_destroy(hbdev->mtd); > + } > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(hyperbus_unregister_device); [...] MBR, Sergei
Hello! On 06/25/2019 10:57 AM, Vignesh Raghavendra wrote: > Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate > Bus interface between a host system master and one or more slave > interfaces. HyperBus is used to connect microprocessor, microcontroller, > or ASIC devices with random access NOR flash memory (called HyperFlash) > or self refresh DRAM (called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in HyperBus > specification[1]. > > HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since HyperBus is x8 DDR bus, > its equivalent to x16 parallel NOR flash with respect to bits per clock > cycle. But HyperBus operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > > But, HyperBus memory controllers seem to abstract implementation details > and expose a simple MMIO interface to access connected flash. > > Add support for registering HyperFlash devices with MTD framework. MTD > maps framework along with CFI chip support framework are used to support > communicating with flash. > > Framework is modelled along the lines of spi-nor framework. HyperBus > memory controller (HBMC) drivers calls hyperbus_register_device() to > register a single HyperFlash device. HyperFlash core parses MMIO access > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > Some HBMC masters need calibration/training sequence[3] to be carried > out, in order for DLL inside the controller to lock, by reading a known > string/pattern. This is done by repeatedly reading CFI Query > Identification String. Calibration needs to be done before trying to detect > flash as part of CFI flash probe. > > HyperRAM is not supported at the moment. > > HyperBus specification can be found at[1] > HyperFlash datasheet can be found at[2] > > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] I have at least created my HyperBus driver and unfortunately I'm having serious issues with the design of the support core (see below)... [...] > diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c > new file mode 100644 > index 000000000000..63a9e64895bc > --- /dev/null > +++ b/drivers/mtd/hyperbus/hyperbus-core.c > @@ -0,0 +1,154 @@ [...] > +int hyperbus_register_device(struct hyperbus_device *hbdev) > +{ > + const struct hyperbus_ops *ops; > + struct hyperbus_ctlr *ctlr; > + struct device_node *np; > + struct map_info *map; > + struct resource res; > + struct device *dev; > + int ret; > + > + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { > + pr_err("hyperbus: please fill all the necessary fields!\n"); > + return -EINVAL; > + } > + > + np = hbdev->np; > + ctlr = hbdev->ctlr; > + if (!of_device_is_compatible(np, "cypress,hyperflash")) > + return -ENODEV; > + > + hbdev->memtype = HYPERFLASH; > + > + ret = of_address_to_resource(np, 0, &res); Hm, I doubt that the HB devices are wholly mapped into memory space, that seems like a property of the HB controller. In my case, the flash device in the DT has only single-cell "reg" prop (equal to the chip select #). Then this function returns -EINVAL and the registration fails. Also, in my case such mapping is R/O, not R/W. > + if (ret) > + return ret; > + > + dev = ctlr->dev; > + map = &hbdev->map; > + map->size = resource_size(&res); > + map->virt = devm_ioremap_resource(dev, &res); > + if (IS_ERR(map->virt)) > + return PTR_ERR(map->virt); Again, I doubt that this should be done here, and not in the HB controller driver... [...] MBR, Sergei
On 02/07/19 11:23 PM, Sergei Shtylyov wrote: > Hello! > > On 06/25/2019 10:57 AM, Vignesh Raghavendra wrote: > >> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate >> Bus interface between a host system master and one or more slave >> interfaces. HyperBus is used to connect microprocessor, microcontroller, >> or ASIC devices with random access NOR flash memory (called HyperFlash) >> or self refresh DRAM (called HyperRAM). >> >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >> signal and either Single-ended clock(3.0V parts) or Differential clock >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >> At bus level, it follows a separate protocol described in HyperBus >> specification[1]. >> >> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, >> its equivalent to x16 parallel NOR flash with respect to bits per clock >> cycle. But HyperBus operates at >166MHz frequencies. >> HyperRAM provides direct random read/write access to flash memory >> array. >> >> But, HyperBus memory controllers seem to abstract implementation details >> and expose a simple MMIO interface to access connected flash. >> >> Add support for registering HyperFlash devices with MTD framework. MTD >> maps framework along with CFI chip support framework are used to support >> communicating with flash. >> >> Framework is modelled along the lines of spi-nor framework. HyperBus >> memory controller (HBMC) drivers calls hyperbus_register_device() to >> register a single HyperFlash device. HyperFlash core parses MMIO access >> information from DT, sets up the map_info struct, probes CFI flash and >> registers it with MTD framework. >> >> Some HBMC masters need calibration/training sequence[3] to be carried >> out, in order for DLL inside the controller to lock, by reading a known >> string/pattern. This is done by repeatedly reading CFI Query >> Identification String. Calibration needs to be done before trying to detect >> flash as part of CFI flash probe. >> >> HyperRAM is not supported at the moment. >> >> HyperBus specification can be found at[1] >> HyperFlash datasheet can be found at[2] >> >> [1] https://www.cypress.com/file/213356/download >> [2] https://www.cypress.com/file/213346/download >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >> Table 12-5741. HyperFlash Access Sequence >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > [...] > > I have at least created my HyperBus driver and unfortunately I'm having serious > issues with the design of the support core (see below)... > > [...] >> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >> new file mode 100644 >> index 000000000000..63a9e64895bc >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >> @@ -0,0 +1,154 @@ > [...] >> +int hyperbus_register_device(struct hyperbus_device *hbdev) >> +{ >> + const struct hyperbus_ops *ops; >> + struct hyperbus_ctlr *ctlr; >> + struct device_node *np; >> + struct map_info *map; >> + struct resource res; >> + struct device *dev; >> + int ret; >> + >> + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { >> + pr_err("hyperbus: please fill all the necessary fields!\n"); >> + return -EINVAL; >> + } >> + >> + np = hbdev->np; >> + ctlr = hbdev->ctlr; >> + if (!of_device_is_compatible(np, "cypress,hyperflash")) >> + return -ENODEV; >> + >> + hbdev->memtype = HYPERFLASH; >> + >> + ret = of_address_to_resource(np, 0, &res); > > Hm, I doubt that the HB devices are wholly mapped into memory space, that seems > like a property of the HB controller. In my case, the flash device in the DT has > only single-cell "reg" prop (equal to the chip select #). Then this function returns > -EINVAL and the registration fails. Also, in my case such mapping is R/O, not R/W. > You could declare R/O MMIO region in controla and set up a translation using ranges from slave's reg CS based reg mapping like: + hbmc: hyperbus@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ + + /* Slave flash node */ + flash@0,0 { + compatible = "cypress,hyperflash", "cfi-flash"; + reg = <0x0 0x0 0x4000000>; + }; + }; If you use just CS# how would you handle CS to MMIO region mapping? Does both CS use the same MMIO base for reads? >> + if (ret) >> + return ret; >> + >> + dev = ctlr->dev; >> + map = &hbdev->map; >> + map->size = resource_size(&res); >> + map->virt = devm_ioremap_resource(dev, &res); >> + if (IS_ERR(map->virt)) >> + return PTR_ERR(map->virt); > > Again, I doubt that this should be done here, and not in the HB controller driver... If multiple CS use same MMIO base, then I can make this part of code non fatal when reg entry is a single cell and introduce notion of CS like SPI > > [...] > > MBR, Sergei >
Hello! On 07/03/2019 07:41 AM, Vignesh Raghavendra wrote: >>> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate >>> Bus interface between a host system master and one or more slave >>> interfaces. HyperBus is used to connect microprocessor, microcontroller, >>> or ASIC devices with random access NOR flash memory (called HyperFlash) >>> or self refresh DRAM (called HyperRAM). >>> >>> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >>> signal and either Single-ended clock(3.0V parts) or Differential clock >>> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >>> At bus level, it follows a separate protocol described in HyperBus >>> specification[1]. >>> >>> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >>> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, >>> its equivalent to x16 parallel NOR flash with respect to bits per clock >>> cycle. But HyperBus operates at >166MHz frequencies. >>> HyperRAM provides direct random read/write access to flash memory >>> array. >>> >>> But, HyperBus memory controllers seem to abstract implementation details >>> and expose a simple MMIO interface to access connected flash. >>> >>> Add support for registering HyperFlash devices with MTD framework. MTD >>> maps framework along with CFI chip support framework are used to support >>> communicating with flash. >>> >>> Framework is modelled along the lines of spi-nor framework. HyperBus >>> memory controller (HBMC) drivers calls hyperbus_register_device() to >>> register a single HyperFlash device. HyperFlash core parses MMIO access >>> information from DT, sets up the map_info struct, probes CFI flash and >>> registers it with MTD framework. >>> >>> Some HBMC masters need calibration/training sequence[3] to be carried >>> out, in order for DLL inside the controller to lock, by reading a known >>> string/pattern. This is done by repeatedly reading CFI Query >>> Identification String. Calibration needs to be done before trying to detect >>> flash as part of CFI flash probe. >>> >>> HyperRAM is not supported at the moment. >>> >>> HyperBus specification can be found at[1] >>> HyperFlash datasheet can be found at[2] >>> >>> [1] https://www.cypress.com/file/213356/download >>> [2] https://www.cypress.com/file/213346/download >>> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >>> Table 12-5741. HyperFlash Access Sequence >>> >>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >> [...] >> >> I have at least created my HyperBus driver and unfortunately I'm having serious At last. :-) >> issues with the design of the support core (see below)... >> >> [...] >>> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >>> new file mode 100644 >>> index 000000000000..63a9e64895bc >>> --- /dev/null >>> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >>> @@ -0,0 +1,154 @@ >> [...] >>> +int hyperbus_register_device(struct hyperbus_device *hbdev) >>> +{ >>> + const struct hyperbus_ops *ops; >>> + struct hyperbus_ctlr *ctlr; >>> + struct device_node *np; >>> + struct map_info *map; >>> + struct resource res; >>> + struct device *dev; >>> + int ret; >>> + >>> + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { >>> + pr_err("hyperbus: please fill all the necessary fields!\n"); >>> + return -EINVAL; >>> + } >>> + >>> + np = hbdev->np; >>> + ctlr = hbdev->ctlr; >>> + if (!of_device_is_compatible(np, "cypress,hyperflash")) >>> + return -ENODEV; >>> + >>> + hbdev->memtype = HYPERFLASH; >>> + >>> + ret = of_address_to_resource(np, 0, &res); >> >> Hm, I doubt that the HB devices are wholly mapped into memory space, that seems >> like a property of the HB controller. In my case, the flash device in the DT has >> only single-cell "reg" prop (equal to the chip select #). Then this function returns >> -EINVAL and the registration fails. Also, in my case such mapping is R/O, not R/W. >> > > You could declare R/O MMIO region in controla and set up a translation using ranges > from slave's reg CS based reg mapping like: No, not all HB controllers work the same (simple) way as yours. In case of RPC-IF, the direct read map is a 64 MiB window into a possibly larger flash chip, it has a register supplying address bits 25:31... > + hbmc: hyperbus@47034000 { > + compatible = "ti,am654-hbmc"; > + reg = <0x0 0x47034000 0x0 0x100>, > + <0x5 0x00000000 0x1 0x0000000>; > + #address-cells = <2>; > + #size-cells = <1>; > + ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ > + <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ > + > + /* Slave flash node */ > + flash@0,0 { > + compatible = "cypress,hyperflash", "cfi-flash"; > + reg = <0x0 0x0 0x4000000>; > + }; > + }; > > If you use just CS# how would you handle CS to MMIO region mapping? > Does both CS use the same MMIO base for reads? The RPC-IF HF mode only has a single CS signal. [...] MBR, Sergei
On 03-Jul-19 11:44 PM, Sergei Shtylyov wrote: > Hello! > > On 07/03/2019 07:41 AM, Vignesh Raghavendra wrote: > >>>> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate >>>> Bus interface between a host system master and one or more slave >>>> interfaces. HyperBus is used to connect microprocessor, microcontroller, >>>> or ASIC devices with random access NOR flash memory (called HyperFlash) >>>> or self refresh DRAM (called HyperRAM). >>>> >>>> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >>>> signal and either Single-ended clock(3.0V parts) or Differential clock >>>> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >>>> At bus level, it follows a separate protocol described in HyperBus >>>> specification[1]. >>>> >>>> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >>>> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, >>>> its equivalent to x16 parallel NOR flash with respect to bits per clock >>>> cycle. But HyperBus operates at >166MHz frequencies. >>>> HyperRAM provides direct random read/write access to flash memory >>>> array. >>>> >>>> But, HyperBus memory controllers seem to abstract implementation details >>>> and expose a simple MMIO interface to access connected flash. >>>> >>>> Add support for registering HyperFlash devices with MTD framework. MTD >>>> maps framework along with CFI chip support framework are used to support >>>> communicating with flash. >>>> >>>> Framework is modelled along the lines of spi-nor framework. HyperBus >>>> memory controller (HBMC) drivers calls hyperbus_register_device() to >>>> register a single HyperFlash device. HyperFlash core parses MMIO access >>>> information from DT, sets up the map_info struct, probes CFI flash and >>>> registers it with MTD framework. >>>> >>>> Some HBMC masters need calibration/training sequence[3] to be carried >>>> out, in order for DLL inside the controller to lock, by reading a known >>>> string/pattern. This is done by repeatedly reading CFI Query >>>> Identification String. Calibration needs to be done before trying to detect >>>> flash as part of CFI flash probe. >>>> >>>> HyperRAM is not supported at the moment. >>>> >>>> HyperBus specification can be found at[1] >>>> HyperFlash datasheet can be found at[2] >>>> >>>> [1] https://www.cypress.com/file/213356/download >>>> [2] https://www.cypress.com/file/213346/download >>>> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >>>> Table 12-5741. HyperFlash Access Sequence >>>> >>>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >>> [...] >>> >>> I have at least created my HyperBus driver and unfortunately I'm having serious > > At last. :-) > So, I guess driver works for limited memory size? >>> issues with the design of the support core (see below)... >>> >>> [...] >>>> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >>>> new file mode 100644 >>>> index 000000000000..63a9e64895bc >>>> --- /dev/null >>>> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >>>> @@ -0,0 +1,154 @@ >>> [...] >>>> +int hyperbus_register_device(struct hyperbus_device *hbdev) >>>> +{ >>>> + const struct hyperbus_ops *ops; >>>> + struct hyperbus_ctlr *ctlr; >>>> + struct device_node *np; >>>> + struct map_info *map; >>>> + struct resource res; >>>> + struct device *dev; >>>> + int ret; >>>> + >>>> + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { >>>> + pr_err("hyperbus: please fill all the necessary fields!\n"); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + np = hbdev->np; >>>> + ctlr = hbdev->ctlr; >>>> + if (!of_device_is_compatible(np, "cypress,hyperflash")) >>>> + return -ENODEV; >>>> + >>>> + hbdev->memtype = HYPERFLASH; >>>> + >>>> + ret = of_address_to_resource(np, 0, &res); >>> >>> Hm, I doubt that the HB devices are wholly mapped into memory space, that seems >>> like a property of the HB controller. In my case, the flash device in the DT has >>> only single-cell "reg" prop (equal to the chip select #). Then this function returns >>> -EINVAL and the registration fails. Also, in my case such mapping is R/O, not R/W. >>> >> >> You could declare R/O MMIO region in controla and set up a translation using ranges >> from slave's reg CS based reg mapping like: > > No, not all HB controllers work the same (simple) way as yours. In case of RPC-IF, > the direct read map is a 64 MiB window into a possibly larger flash chip, it has a > register supplying address bits 25:31... Okay, this limitation was not made clear earlier. I thought RPC-IF also supported MMIO accesses for all reads I will look into changes needed to support HB controllers that don't have MMIO interface next week. Regards Vignesh > >> + hbmc: hyperbus@47034000 { >> + compatible = "ti,am654-hbmc"; >> + reg = <0x0 0x47034000 0x0 0x100>, >> + <0x5 0x00000000 0x1 0x0000000>; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ >> + <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ >> + >> + /* Slave flash node */ >> + flash@0,0 { >> + compatible = "cypress,hyperflash", "cfi-flash"; >> + reg = <0x0 0x0 0x4000000>; >> + }; >> + }; >> >> If you use just CS# how would you handle CS to MMIO region mapping? >> Does both CS use the same MMIO base for reads? > > The RPC-IF HF mode only has a single CS signal. > I see... > [...] > > MBR, Sergei > Regards Vignesh
Hello! On 06/25/2019 10:57 AM, Vignesh Raghavendra wrote: > Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate > Bus interface between a host system master and one or more slave > interfaces. HyperBus is used to connect microprocessor, microcontroller, > or ASIC devices with random access NOR flash memory (called HyperFlash) > or self refresh DRAM (called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in HyperBus > specification[1]. > > HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since HyperBus is x8 DDR bus, > its equivalent to x16 parallel NOR flash with respect to bits per clock > cycle. But HyperBus operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > > But, HyperBus memory controllers seem to abstract implementation details > and expose a simple MMIO interface to access connected flash. > > Add support for registering HyperFlash devices with MTD framework. MTD > maps framework along with CFI chip support framework are used to support > communicating with flash. > > Framework is modelled along the lines of spi-nor framework. HyperBus > memory controller (HBMC) drivers calls hyperbus_register_device() to > register a single HyperFlash device. HyperFlash core parses MMIO access > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > Some HBMC masters need calibration/training sequence[3] to be carried > out, in order for DLL inside the controller to lock, by reading a known > string/pattern. This is done by repeatedly reading CFI Query > Identification String. Calibration needs to be done before trying to detect > flash as part of CFI flash probe. > > HyperRAM is not supported at the moment. > > HyperBus specification can be found at[1] > HyperFlash datasheet can be found at[2] > > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c > new file mode 100644 > index 000000000000..63a9e64895bc > --- /dev/null > +++ b/drivers/mtd/hyperbus/hyperbus-core.c > @@ -0,0 +1,154 @@ [...] > +int hyperbus_register_device(struct hyperbus_device *hbdev) > +{ [...] > + map->name = dev_name(dev); > + map->bankwidth = 2; I think this should really be 1, judging on the comment to that field (and on Cogent's own RPC-IF HF driver). > + map->device_node = np; [...] MBR, Sergei
On 12/07/19 12:56 AM, Sergei Shtylyov wrote: > Hello! > > On 06/25/2019 10:57 AM, Vignesh Raghavendra wrote: > >> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate >> Bus interface between a host system master and one or more slave >> interfaces. HyperBus is used to connect microprocessor, microcontroller, >> or ASIC devices with random access NOR flash memory (called HyperFlash) >> or self refresh DRAM (called HyperRAM). >> >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >> signal and either Single-ended clock(3.0V parts) or Differential clock >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >> At bus level, it follows a separate protocol described in HyperBus >> specification[1]. >> >> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, >> its equivalent to x16 parallel NOR flash with respect to bits per clock >> cycle. But HyperBus operates at >166MHz frequencies. >> HyperRAM provides direct random read/write access to flash memory >> array. >> >> But, HyperBus memory controllers seem to abstract implementation details >> and expose a simple MMIO interface to access connected flash. >> >> Add support for registering HyperFlash devices with MTD framework. MTD >> maps framework along with CFI chip support framework are used to support >> communicating with flash. >> >> Framework is modelled along the lines of spi-nor framework. HyperBus >> memory controller (HBMC) drivers calls hyperbus_register_device() to >> register a single HyperFlash device. HyperFlash core parses MMIO access >> information from DT, sets up the map_info struct, probes CFI flash and >> registers it with MTD framework. >> >> Some HBMC masters need calibration/training sequence[3] to be carried >> out, in order for DLL inside the controller to lock, by reading a known >> string/pattern. This is done by repeatedly reading CFI Query >> Identification String. Calibration needs to be done before trying to detect >> flash as part of CFI flash probe. >> >> HyperRAM is not supported at the moment. >> >> HyperBus specification can be found at[1] >> HyperFlash datasheet can be found at[2] >> >> [1] https://www.cypress.com/file/213356/download >> [2] https://www.cypress.com/file/213346/download >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >> Table 12-5741. HyperFlash Access Sequence >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > [...] > >> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >> new file mode 100644 >> index 000000000000..63a9e64895bc >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >> @@ -0,0 +1,154 @@ > [...] >> +int hyperbus_register_device(struct hyperbus_device *hbdev) >> +{ > [...] >> + map->name = dev_name(dev); >> + map->bankwidth = 2; > > I think this should really be 1, judging on the comment to that field (and on > Cogent's own RPC-IF HF driver). > I agree this setting is a bit confusing because DDR nature. What we have with HyperFlash in DDR mode is equivalent to 16bit flash on a 8bit bus and kind of equal to 2 bus cycles (in this case clock edges), therefore bandwidth would turn out to be 2. Otherwise cfi_build_cmd() would generate wrong addresses and simple map implmention of read/writes would use wrong accessors. Only way I see map->bankwidth = 1 working is if HF is used in SDR mode. So is Cogent's HF in SDR mode? I thought HyperFlash is DDR only but I may be wrong. >> + map->device_node = np; > > [...] > > MBR, Sergei >
Hi Vignesh, On Tue, Jun 25, 2019 at 10:00 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: > Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate > Bus interface between a host system master and one or more slave > interfaces. HyperBus is used to connect microprocessor, microcontroller, > or ASIC devices with random access NOR flash memory (called HyperFlash) > or self refresh DRAM (called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in HyperBus > specification[1]. > > HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since HyperBus is x8 DDR bus, > its equivalent to x16 parallel NOR flash with respect to bits per clock > cycle. But HyperBus operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > > But, HyperBus memory controllers seem to abstract implementation details > and expose a simple MMIO interface to access connected flash. > > Add support for registering HyperFlash devices with MTD framework. MTD > maps framework along with CFI chip support framework are used to support > communicating with flash. > > Framework is modelled along the lines of spi-nor framework. HyperBus > memory controller (HBMC) drivers calls hyperbus_register_device() to > register a single HyperFlash device. HyperFlash core parses MMIO access > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > Some HBMC masters need calibration/training sequence[3] to be carried > out, in order for DLL inside the controller to lock, by reading a known > string/pattern. This is done by repeatedly reading CFI Query > Identification String. Calibration needs to be done before trying to detect > flash as part of CFI flash probe. > > HyperRAM is not supported at the moment. Thanks for your patch, which is now commit dcc7d3446a0fa19b ("mtd: Add support for HyperBus memory devices") in v5.3. > HyperBus specification can be found at[1] > HyperFlash datasheet can be found at[2] > > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence The last link no longer works. Do you have a replacement? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert, On 6/27/2022 8:58 PM, Geert Uytterhoeven wrote: > Hi Vignesh, > > On Tue, Jun 25, 2019 at 10:00 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: >> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate >> Bus interface between a host system master and one or more slave >> interfaces. HyperBus is used to connect microprocessor, microcontroller, >> or ASIC devices with random access NOR flash memory (called HyperFlash) >> or self refresh DRAM (called HyperRAM). >> >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >> signal and either Single-ended clock(3.0V parts) or Differential clock >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >> At bus level, it follows a separate protocol described in HyperBus >> specification[1]. >> >> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, >> its equivalent to x16 parallel NOR flash with respect to bits per clock >> cycle. But HyperBus operates at >166MHz frequencies. >> HyperRAM provides direct random read/write access to flash memory >> array. >> >> But, HyperBus memory controllers seem to abstract implementation details >> and expose a simple MMIO interface to access connected flash. >> >> Add support for registering HyperFlash devices with MTD framework. MTD >> maps framework along with CFI chip support framework are used to support >> communicating with flash. >> >> Framework is modelled along the lines of spi-nor framework. HyperBus >> memory controller (HBMC) drivers calls hyperbus_register_device() to >> register a single HyperFlash device. HyperFlash core parses MMIO access >> information from DT, sets up the map_info struct, probes CFI flash and >> registers it with MTD framework. >> >> Some HBMC masters need calibration/training sequence[3] to be carried >> out, in order for DLL inside the controller to lock, by reading a known >> string/pattern. This is done by repeatedly reading CFI Query >> Identification String. Calibration needs to be done before trying to detect >> flash as part of CFI flash probe. >> >> HyperRAM is not supported at the moment. > > Thanks for your patch, which is now commit dcc7d3446a0fa19b ("mtd: > Add support for HyperBus memory devices") in v5.3. > >> HyperBus specification can be found at[1] >> HyperFlash datasheet can be found at[2] >> >> [1] https://www.cypress.com/file/213356/download >> [2] https://www.cypress.com/file/213346/download >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >> Table 12-5741. HyperFlash Access Sequence > > The last link no longer works. Do you have a replacement? Looks like I used a link point to specific version instead of top level redirector link. Please use: https://www.ti.com/lit/pdf/spruid7 Regards Vignesh
Hi Vignesh, On Sat, Jul 2, 2022 at 7:10 PM Raghavendra, Vignesh <vigneshr@ti.com> wrote: > On 6/27/2022 8:58 PM, Geert Uytterhoeven wrote: > > On Tue, Jun 25, 2019 at 10:00 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate > >> Bus interface between a host system master and one or more slave > >> interfaces. HyperBus is used to connect microprocessor, microcontroller, > >> or ASIC devices with random access NOR flash memory (called HyperFlash) > >> or self refresh DRAM (called HyperRAM). > >> > >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > >> signal and either Single-ended clock(3.0V parts) or Differential clock > >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > >> At bus level, it follows a separate protocol described in HyperBus > >> specification[1]. > >> > >> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > >> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, > >> its equivalent to x16 parallel NOR flash with respect to bits per clock > >> cycle. But HyperBus operates at >166MHz frequencies. > >> HyperRAM provides direct random read/write access to flash memory > >> array. > >> > >> But, HyperBus memory controllers seem to abstract implementation details > >> and expose a simple MMIO interface to access connected flash. > >> > >> Add support for registering HyperFlash devices with MTD framework. MTD > >> maps framework along with CFI chip support framework are used to support > >> communicating with flash. > >> > >> Framework is modelled along the lines of spi-nor framework. HyperBus > >> memory controller (HBMC) drivers calls hyperbus_register_device() to > >> register a single HyperFlash device. HyperFlash core parses MMIO access > >> information from DT, sets up the map_info struct, probes CFI flash and > >> registers it with MTD framework. > >> > >> Some HBMC masters need calibration/training sequence[3] to be carried > >> out, in order for DLL inside the controller to lock, by reading a known > >> string/pattern. This is done by repeatedly reading CFI Query > >> Identification String. Calibration needs to be done before trying to detect > >> flash as part of CFI flash probe. > >> > >> HyperRAM is not supported at the moment. > > > > Thanks for your patch, which is now commit dcc7d3446a0fa19b ("mtd: > > Add support for HyperBus memory devices") in v5.3. > > > >> HyperBus specification can be found at[1] > >> HyperFlash datasheet can be found at[2] > >> > >> [1] https://www.cypress.com/file/213356/download > >> [2] https://www.cypress.com/file/213346/download > >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > >> Table 12-5741. HyperFlash Access Sequence > > > > The last link no longer works. Do you have a replacement? > > Looks like I used a link point to specific version instead of top level > redirector link. Please use: > > https://www.ti.com/lit/pdf/spruid7 Thank you, that link works for me. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/MAINTAINERS b/MAINTAINERS index 10359a30ed3c..c4860e53c695 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7363,6 +7363,13 @@ F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus +HYPERBUS SUPPORT +M: Vignesh Raghavendra <vigneshr@ti.com> +S: Supported +F: drivers/mtd/hyperbus/ +F: include/linux/mtd/hyperbus.h +F: Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt + HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org S: Odd Fixes diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index fb31a7f649a3..80a6e2dcd085 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -274,4 +274,6 @@ source "drivers/mtd/spi-nor/Kconfig" source "drivers/mtd/ubi/Kconfig" +source "drivers/mtd/hyperbus/Kconfig" + endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 806287e80e84..62d649a959e2 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -34,3 +34,4 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/ obj-$(CONFIG_MTD_UBI) += ubi/ +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus/ diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig new file mode 100644 index 000000000000..98147e28caa0 --- /dev/null +++ b/drivers/mtd/hyperbus/Kconfig @@ -0,0 +1,11 @@ +menuconfig MTD_HYPERBUS + tristate "HyperBus support" + select MTD_CFI + select MTD_MAP_BANK_WIDTH_2 + select MTD_CFI_AMDSTD + select MTD_COMPLEX_MAPPINGS + help + This is the framework for the HyperBus which can be used by + the HyperBus Controller driver to communicate with + HyperFlash. See Cypress HyperBus specification for more + details diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile new file mode 100644 index 000000000000..ca61dedd730d --- /dev/null +++ b/drivers/mtd/hyperbus/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c new file mode 100644 index 000000000000..63a9e64895bc --- /dev/null +++ b/drivers/mtd/hyperbus/hyperbus-core.c @@ -0,0 +1,154 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/map.h> +#include <linux/mtd/mtd.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/types.h> + +static struct hyperbus_device *map_to_hbdev(struct map_info *map) +{ + return container_of(map, struct hyperbus_device, map); +} + +static map_word hyperbus_read16(struct map_info *map, unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + map_word read_data; + + read_data.x[0] = ctlr->ops->read16(hbdev, addr); + + return read_data; +} + +static void hyperbus_write16(struct map_info *map, map_word d, + unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->write16(hbdev, addr, d.x[0]); +} + +static void hyperbus_copy_from(struct map_info *map, void *to, + unsigned long from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_from(hbdev, to, from, len); +} + +static void hyperbus_copy_to(struct map_info *map, unsigned long to, + const void *from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_to(hbdev, to, from, len); +} + +int hyperbus_register_device(struct hyperbus_device *hbdev) +{ + const struct hyperbus_ops *ops; + struct hyperbus_ctlr *ctlr; + struct device_node *np; + struct map_info *map; + struct resource res; + struct device *dev; + int ret; + + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { + pr_err("hyperbus: please fill all the necessary fields!\n"); + return -EINVAL; + } + + np = hbdev->np; + ctlr = hbdev->ctlr; + if (!of_device_is_compatible(np, "cypress,hyperflash")) + return -ENODEV; + + hbdev->memtype = HYPERFLASH; + + ret = of_address_to_resource(np, 0, &res); + if (ret) + return ret; + + dev = ctlr->dev; + map = &hbdev->map; + map->size = resource_size(&res); + map->virt = devm_ioremap_resource(dev, &res); + if (IS_ERR(map->virt)) + return PTR_ERR(map->virt); + + map->name = dev_name(dev); + map->bankwidth = 2; + map->device_node = np; + + simple_map_init(map); + ops = ctlr->ops; + if (ops) { + if (ops->read16) + map->read = hyperbus_read16; + if (ops->write16) + map->write = hyperbus_write16; + if (ops->copy_to) + map->copy_to = hyperbus_copy_to; + if (ops->copy_from) + map->copy_from = hyperbus_copy_from; + + if (ops->calibrate && !ctlr->calibrated) { + ret = ops->calibrate(hbdev); + if (!ret) { + dev_err(dev, "Calibration failed\n"); + return -ENODEV; + } + ctlr->calibrated = true; + } + } + + hbdev->mtd = do_map_probe("cfi_probe", map); + if (!hbdev->mtd) { + dev_err(dev, "probing of hyperbus device failed\n"); + return -ENODEV; + } + + hbdev->mtd->dev.parent = dev; + mtd_set_of_node(hbdev->mtd, np); + + ret = mtd_device_register(hbdev->mtd, NULL, 0); + if (ret) { + dev_err(dev, "failed to register mtd device\n"); + map_destroy(hbdev->mtd); + return ret; + } + hbdev->registered = true; + + return 0; +} +EXPORT_SYMBOL_GPL(hyperbus_register_device); + +int hyperbus_unregister_device(struct hyperbus_device *hbdev) +{ + int ret = 0; + + if (hbdev && hbdev->mtd && hbdev->registered) { + ret = mtd_device_unregister(hbdev->mtd); + map_destroy(hbdev->mtd); + } + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_unregister_device); + +MODULE_DESCRIPTION("HyperBus Framework"); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h new file mode 100644 index 000000000000..45c59152f116 --- /dev/null +++ b/include/linux/mtd/hyperbus.h @@ -0,0 +1,86 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#ifndef __LINUX_MTD_HYPERBUS_H__ +#define __LINUX_MTD_HYPERBUS_H__ + +#include <linux/mtd/map.h> + +enum hyperbus_memtype { + HYPERFLASH, + HYPERRAM, +}; + +/** + * struct hyperbus_device - struct representing HyperBus slave device + * @map: map_info struct for accessing MMIO HyperBus flash memory + * @np: pointer to HyperBus slave device node + * @mtd: pointer to MTD struct + * @ctlr: pointer to HyperBus controller struct + * @memtype: type of memory device: HyperFlash or HyperRAM + * @registered: flag to indicate whether device is registered with MTD core + */ + +struct hyperbus_device { + struct map_info map; + struct device_node *np; + struct mtd_info *mtd; + struct hyperbus_ctlr *ctlr; + enum hyperbus_memtype memtype; + bool registered; +}; + +/** + * struct hyperbus_ops - struct representing custom HyperBus operations + * @read16: read 16 bit of data from flash in a single burst. Used to read + * from non default address space, such as ID/CFI space + * @write16: write 16 bit of data to flash in a single burst. Used to + * send cmd to flash or write single 16 bit word at a time. + * @copy_from: copy data from flash memory + * @copy_to: copy data to flash memory + * @calibrate: calibrate HyperBus controller + */ + +struct hyperbus_ops { + u16 (*read16)(struct hyperbus_device *hbdev, unsigned long addr); + void (*write16)(struct hyperbus_device *hbdev, + unsigned long addr, u16 val); + void (*copy_from)(struct hyperbus_device *hbdev, void *to, + unsigned long from, ssize_t len); + void (*copy_to)(struct hyperbus_device *dev, unsigned long to, + const void *from, ssize_t len); + int (*calibrate)(struct hyperbus_device *dev); +}; + +/** + * struct hyperbus_ctlr - struct representing HyperBus controller + * @dev: pointer to HyperBus controller device + * @calibrated: flag to indicate ctlr calibration sequence is complete + * @ops: HyperBus controller ops + */ +struct hyperbus_ctlr { + struct device *dev; + bool calibrated; + + const struct hyperbus_ops *ops; +}; + +/** + * hyperbus_register_device - probe and register a HyperBus slave memory device + * @hbdev: hyperbus_device struct with dev, np and ctlr field populated + * + * Return: 0 for success, others for failure. + */ +int hyperbus_register_device(struct hyperbus_device *hbdev); + +/** + * hyperbus_unregister_device - deregister HyperBus slave memory device + * @hbdev: hyperbus_device to be unregistered + * + * Return: 0 for success, others for failure. + */ +int hyperbus_unregister_device(struct hyperbus_device *hbdev); + +#endif /* __LINUX_MTD_HYPERBUS_H__ */
Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory (called HyperFlash) or self refresh DRAM (called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since HyperBus is x8 DDR bus, its equivalent to x16 parallel NOR flash with respect to bits per clock cycle. But HyperBus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. But, HyperBus memory controllers seem to abstract implementation details and expose a simple MMIO interface to access connected flash. Add support for registering HyperFlash devices with MTD framework. MTD maps framework along with CFI chip support framework are used to support communicating with flash. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller (HBMC) drivers calls hyperbus_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. Some HBMC masters need calibration/training sequence[3] to be carried out, in order for DLL inside the controller to lock, by reading a known string/pattern. This is done by repeatedly reading CFI Query Identification String. Calibration needs to be done before trying to detect flash as part of CFI flash probe. HyperRAM is not supported at the moment. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- v8: Fix documentation comments on core APIs MAINTAINERS | 7 ++ drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/hyperbus/Kconfig | 11 ++ drivers/mtd/hyperbus/Makefile | 3 + drivers/mtd/hyperbus/hyperbus-core.c | 154 +++++++++++++++++++++++++++ include/linux/mtd/hyperbus.h | 86 +++++++++++++++ 7 files changed, 264 insertions(+) create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h