Re: [RFC PATCH 3/5] mtd: Add support for Hyperbus memory devices
On 24/02/19 1:49 AM, Sergei Shtylyov wrote: > Hello! > > On 02/19/2019 09:36 AM, Vignesh R (by way of Boris Brezillon > ) 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 > > Need space before (. > >> 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 wrt bits per clk. 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 >> communicate with flash. > >Communicating. > >> Framework is modelled along the lines of spi-nor framework. HyperBus >> memory controller(HBMC) drivers call hb_register_device() to register a > >Again, space needed before (. > >> 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 try to detect > >Trying. > >> flash as part of CFI flash probe. >> >> HyperRAM is not supported atm. > >ATM? > >> 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 R > [...] >> diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig >> new file mode 100644 >> index ..02c38afc5c50 >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/Kconfig >> @@ -0,0 +1,23 @@ >> +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 commmunicate with > ^^^ > Too many m's. :-) > >> + Hyperflash. See Cypress Hyperbus specification for more >> + details >> + >> + >> +if MTD_HYPERBUS >> + >> +config HBMC_AM654 >> +tristate "Hyperbus controller driver for AM65x SoC" >> +help >> + This is the driver for Hyperbus controller on TI's AM65x and >> + other SoCs >> + >> +endif # MTD_HYPERBUS > > The above clearly belongs to patch #5. > >> + > >No empty lines at end of file, please... > >> diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile >> new file mode 100644 >> index ..64e377d7f636 >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/Makefile >> @@ -0,0 +1,4 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> + >> +obj-$(CONFIG_MTD_HYPERBUS) += core.o >> +obj-$(CONFIG_HBMC_AM654)+= hbmc_am654.o > >The above line clearly belongs to patch #5 as well... > >> diff --git a/drivers/mtd/hyperbus/core.c b/drivers/mtd/hyperbus/core.c >> new file mode 100644 >> index ..d3d44aab7503 >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/core.c >> @@ -0,0 +1,167 @@ >> +// SPDX-License-Ident
Re: [RFC PATCH 3/5] mtd: Add support for Hyperbus memory devices
On 26/02/19 1:03 AM, Sergei Shtylyov wrote:
> On 02/25/2019 09:21 PM, Vignesh R wrote:
>
> [...]
>
>>>> 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 R
> [...]
>>>> diff --git a/drivers/mtd/hyperbus/core.c b/drivers/mtd/hyperbus/core.c
>>>> new file mode 100644
>>>> index ..d3d44aab7503
>>>> --- /dev/null
>>>> +++ b/drivers/mtd/hyperbus/core.c
> [...]
>>>> +int hb_register_device(struct hb_device *hbdev)
>>>> +{
>>>> + struct resource res;
>>>> + struct device *dev;
>>>> + struct device_node *np;
>>>> + struct map_info *map;
>>>> + struct hb_ops *ops;
>>>> + int err;
>>>> +
>>>> + if (!hbdev || !hbdev->dev || !hbdev->np) {
>>>> + pr_err("hyperbus: please fill all the necessary fields!\n");
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + np = hbdev->np;
>>>> + if (!of_device_is_compatible(np, "cypress,hyperflash"))
>>>> + return -ENODEV;
>>>> +
>>>> + hbdev->memtype = HYPERFLASH;
>>>> +
>>>> + if (of_address_to_resource(np, 0, ))
>>>
>>> Isn't the direct mapping property of the HF controller, not of
>>> HyperFlash
>>> itself?
>>>
>>
>> As I said in the cover letter, I could not find many examples of HF
>> controllers, but couple of them that I studied provide MMIO access to
>> flash. So, reg property of flash node would represent local address on
>> the HyperBus and controller node would set up ranges properly to provide
>> translation from CS to SoC address space.
>> For example see patch 4/5 where reg property would indicate CS and Size
>> of flash. This scheme is similar to whats described here [1]
>> HBMC controllers usually have different MMIO regions to access flashes
>> connected to different CS. So using ranges for address translation along
>> with flash node describing local address works pretty well.
>>
>> My understanding is that this part of code will be common for most MMIO
>> based HB controllers and hence made part of core layer. But, if
>> controllers uses different IO space for read vs write, then this needs a
>> bit of thinking. In that case, mapping needs to be moved to controller
>> drivers.
>>
>> [1]https://elinux.org/Device_Tree_Usage#Ranges_.28Address_Translation.29
>>
>>>> + return -EINVAL;
>>>> +
>>>> + dev = hbdev->dev;
>>>> + map = >map;
>>>> + map->size = resource_size();
>>>> + map->virt = devm_ioremap_resource(dev, );
>>>> + if (IS_ERR(map->virt))
>>>> + return PTR_ERR(map->virt);
>>>> +
>>>> + map->name = dev_name(dev);
>>>> + map->bankwidth = 2;
>>>> +
>>>> + simple_map_init(map);
>>>
>>>It's not that simple, I'm afraid -- e.g. Renesas RPC-IF has read and
>>> write
>>> mappings in the separate memory resources.
>>>
>>
>> Hmm, could you point me to public datasheet of the controller?
>
>See chapter 20 in [1]. Note that it's not the same SoC I'm developing for
> (R-Car
> gen3 family, with NDA docs) but should be mostly the same RPC-IF core.
>
> [1]
> https://www.renesas.com/us/en/doc/products/mpumcu/doc/rz/r01uh0746ej0200-rza2m.pdf?key=74862185b5e22ad09e648d21a35de615
Thanks for the info!
>
>> simple_map_init() provides default implementation for map operations
>> which is overridden, if hb_ops is populated.
>> I think, Renesas RPC-IF can populate custom hb_ops struct and use
>> appropriate MMIO base for read vs write, while still reusing the map
>> framework. Wouldnt that work?
>
>It probably would...
>
Looking at above link, I see there are two HBMC controllers on Renesas
SoC. One is a dedicated HBMC controller(chapter 21) very similar to that
on TI SoC and a SPI Multi I/O Bus Controller (chapter 20) that also
supports Hyperbus protocol.
AFAICS, passing custom hb_ops is good enough to support both HW needs.
Let me know if something is missing. I would greatly appreciate if you
could test this series with your HW.
--
Regards
Vignesh
Re: [RFC PATCH 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller
On 25/02/19 9:59 PM, Sergei Shtylyov wrote:
> Hello!
>
> On 02/19/2019 09:36 AM, Vignesh R (by way of Boris Brezillon
> ) wrote:
>
>> Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming
>> IP is pretty simple and provides direct memory mapped access to
>> connected Flash devices.
>
>Are you sure you posted the _complete_ driver?
>
Yes, it is... You can find controller doc here[1]. Default values in the
MCR/MTR registers are good enough to simple Hyperflash access.
More perf optimization and timing optimizations will come incrementally
[1] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf 12.3.3 Hyperbus Interface
>> Add basic support for the IP without DMA. Second ChipSelect is not
>> supported for now.
>>
>> Signed-off-by: Vignesh R
>> ---
>> drivers/mtd/hyperbus/hbmc_am654.c | 105 ++
>> 1 file changed, 105 insertions(+)
>> create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c
>>
>> diff --git a/drivers/mtd/hyperbus/hbmc_am654.c
>> b/drivers/mtd/hyperbus/hbmc_am654.c
>> new file mode 100644
>> index ..1f0d2dc52f9f
>> --- /dev/null
>> +++ b/drivers/mtd/hyperbus/hbmc_am654.c
>> @@ -0,0 +1,105 @@
> [...]
>> +static int am654_hbmc_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct am654_hbmc_priv *priv;
>> +struct resource *res;
>> +int err;
>> +
>> +priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
>> +if (!priv)
>> +return -ENOMEM;
>> +
>> +platform_set_drvdata(pdev, priv);
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +if (IS_ERR(res)) {
>> +dev_err(>dev, "failed to get memory resource\n");
>> +return -ENOENT;
>> +}
>> +
>> +priv->regbase = devm_ioremap_resource(dev, res);
>> +if (IS_ERR(priv->regbase)) {
>> +dev_err(dev, "Cannot remap controller address.\n");
>> +return PTR_ERR(priv->regbase);
>> +}
>> +
>> +pm_runtime_enable(>dev);
>> +err = pm_runtime_get_sync(>dev);
>
>That's all nice but where's the code that accesses the actual registers?
Interface and functional clk needs to be enabled even to access MMIO
space to read/write data to flash (done by the map framework). So driver
currently just enables everything during probe and disables on remove
>
>> +if (err < 0) {
>> +pm_runtime_put_noidle(>dev);
>
>Calling "put" with previously failed "get" sees strange...
>
Basically pm_runtime_get_sync() increments usage_count even in case of
failure and pm_runtime_put_noidle() puts it back. You can find many
examples of above piece of code in kernel.
>> +return err;
>> +}
>> +
>> +priv->hbdev.needs_calib = true;
>> +priv->hbdev.dev = >dev;
>> +priv->hbdev.np = of_get_next_child(dev->of_node, NULL);
>> +err = hb_register_device(>hbdev);
>> +if (err) {
>> +dev_err(>dev, "failed to register controller\n");
>> +goto err_destroy;
>> +}
>> +
>> +return 0;
>> +
>> +err_destroy:
>> +hb_unregister_device(>hbdev);
>
>Calling "unregister" with "register" previously failed also looks
> strange...
>
Agree, this is unneeded as hb_register_device() takes care of all
cleanups in err path.
>> +pm_runtime_put_sync(>dev);
>
>Why the sync() version?
>
Why not? Since the device is going away, I think its safer to ensure
device has definitely been put to idle state. I see its a common
practice in driver code.
>> +return err;
>> +}
> [...]
>
> MBR, Sergei
>
--
Regards
Vignesh
Re: [RFC PATCH 3/5] mtd: Add support for Hyperbus memory devices
Hi Sergei, On 24/02/19 1:49 AM, Sergei Shtylyov wrote: > Hello! > > On 02/19/2019 09:36 AM, Vignesh R (by way of Boris Brezillon > ) 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 > > Need space before (. > >> 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 wrt bits per clk. 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 >> communicate with flash. > >Communicating. > >> Framework is modelled along the lines of spi-nor framework. HyperBus >> memory controller(HBMC) drivers call hb_register_device() to register a > >Again, space needed before (. > >> 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 try to detect > >Trying. > >> flash as part of CFI flash probe. >> >> HyperRAM is not supported atm. > >ATM? > >> 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 R > [...] >> diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig >> new file mode 100644 >> index ..02c38afc5c50 >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/Kconfig >> @@ -0,0 +1,23 @@ >> +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 commmunicate with > ^^^ > Too many m's. :-) > >> + Hyperflash. See Cypress Hyperbus specification for more >> + details >> + >> + >> +if MTD_HYPERBUS >> + >> +config HBMC_AM654 >> +tristate "Hyperbus controller driver for AM65x SoC" >> +help >> + This is the driver for Hyperbus controller on TI's AM65x and >> + other SoCs >> + >> +endif # MTD_HYPERBUS > > The above clearly belongs to patch #5. > >> + > >No empty lines at end of file, please... > >> diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile >> new file mode 100644 >> index ..64e377d7f636 >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/Makefile >> @@ -0,0 +1,4 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> + >> +obj-$(CONFIG_MTD_HYPERBUS) += core.o >> +obj-$(CONFIG_HBMC_AM654)+= hbmc_am654.o > >The above line clearly belongs to patch #5 as well... Right, will fix this and all the above comments. > >> diff --git a/drivers/mtd/hyperbus/core.c b/drivers/mtd/hyperbus/core.c >> new file mode 100644 >> index ..d3d44aab7503 >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/core.c >
Re: [PATCH v2] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
On 22-Feb-19 8:20 PM, liujian (CE) wrote:
>
>> -Original Message-
>> From: Vignesh R [mailto:vigne...@ti.com]
>> Sent: Friday, February 22, 2019 1:59 PM
>> To: liujian (CE) ; dw...@infradead.org;
>> computersforpe...@gmail.com; bbrezil...@kernel.org;
>> marek.va...@gmail.com; rich...@nod.at; joakim.tjernl...@infinera.com;
>> ikeg...@allied-telesis.co.jp; keesc...@chromium.org
>> Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v2] cfi: fix deadloop in cfi_cmdset_0002.c
>> do_write_buffer
>>
>>
>>
>> On 20/02/19 2:17 AM, Liu Jian wrote:
>>> In function do_write_buffer(), in the for loop, there is a case
>>> chip_ready() returns 1 while chip_good() returns 0, so it never break
>>> the loop.
>>> To fix this, chip_good() is enough and it should timeout if it stay
>>> bad for a while.
>>>
>>> Fixes: dfeae1073583 ("mtd: cfi_cmdset_0002: Change write buffer to
>>> check correct value")
>>> Signed-off-by: Yi Huaijie
>>> Signed-off-by: Liu Jian
>>> Reviewed-by: Tokunori Ikegami
>>> ---
>>> v1->v2:
>>> change git log, put the Fixes tag on a single line
>>>
>>> drivers/mtd/chips/cfi_cmdset_0002.c | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
>>> b/drivers/mtd/chips/cfi_cmdset_0002.c
>>> index 72428b6..818e94b 100644
>>> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
>>> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
>>> @@ -1876,14 +1876,14 @@ static int __xipram do_write_buffer(struct
>> map_info *map, struct flchip *chip,
>>> continue;
>>> }
>>>
>>> - if (time_after(jiffies, timeo) && !chip_ready(map, adr))
>>> - break;
>>> -
>>> if (chip_good(map, adr, datum)) {
>>> xip_enable(map, chip, adr);
>>> goto op_done;
>>> }
>>>
>>> + if (time_after(jiffies, timeo))
>>> + break;
>>> +
>>
>> It is quite possible that this thread might be pre-empted just after
>> chip_good() check but before before time_after(). If the thread, then resumes
>> execution after timeo has elasped then, this code will wrongly indicate write
>> failure.
>>
>> To avoid this case, you should add one more check for check_good() even when
>> time_after() returns true. Something like:
>>
>> if (time_after(jiffies, timeo)) {
>> if (chip_good(map, adr, datum)) {
>> xip_enable(map, chip, adr);
>> goto op_done;
>> }
>> break;
>> }
>>
> So, the patch should like this ?
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
> b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 72428b6..3da2376 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -1876,7 +1876,7 @@ static int __xipram do_write_buffer(struct map_info
> *map, struct flchip *chip,
> continue;
> }
>
> - if (time_after(jiffies, timeo) && !chip_ready(map, adr))
> + if (time_after(jiffies, timeo) && !chip_good(map, adr, datum))
> break;
>
> if (chip_good(map, adr, datum)) {
>
>
>
> Any other opinions?
> If there are no other comments, I will send a patch again
Looks fine to me.. Please submit a new version. Thanks!
Regards
Vignesh
Re: [PATCH v2] cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
On 20/02/19 2:17 AM, Liu Jian wrote:
> In function do_write_buffer(), in the for loop, there is a case
> chip_ready() returns 1 while chip_good() returns 0, so it never
> break the loop.
> To fix this, chip_good() is enough and it should timeout if it stay
> bad for a while.
>
> Fixes: dfeae1073583 ("mtd: cfi_cmdset_0002: Change write buffer to check
> correct value")
> Signed-off-by: Yi Huaijie
> Signed-off-by: Liu Jian
> Reviewed-by: Tokunori Ikegami
> ---
> v1->v2:
> change git log, put the Fixes tag on a single line
>
> drivers/mtd/chips/cfi_cmdset_0002.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
> b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 72428b6..818e94b 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -1876,14 +1876,14 @@ static int __xipram do_write_buffer(struct map_info
> *map, struct flchip *chip,
> continue;
> }
>
> - if (time_after(jiffies, timeo) && !chip_ready(map, adr))
> - break;
> -
> if (chip_good(map, adr, datum)) {
> xip_enable(map, chip, adr);
> goto op_done;
> }
>
> + if (time_after(jiffies, timeo))
> + break;
> +
It is quite possible that this thread might be pre-empted just after
chip_good() check but before before time_after(). If the thread, then
resumes execution after timeo has elasped then, this code will wrongly
indicate write failure.
To avoid this case, you should add one more check for check_good() even
when time_after() returns true. Something like:
if (time_after(jiffies, timeo)) {
if (chip_good(map, adr, datum)) {
xip_enable(map, chip, adr);
goto op_done;
}
break;
}
> /* Latency issues. Drop the lock, wait a while and retry */
> UDELAY(map, chip, adr, 1);
> }
>
--
Regards
Vignesh
Re: [EXT] [PATCH v6 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
On 21/02/19 4:11 PM, Bean Huo (beanhuo) wrote: > Hi, Vignesh > >> >> Cadence OSPI controller IP supports Octal IO (x8 IO lines), It also has an >> integrated PHY. IP register layout is very similar to existing QSPI IP >> except for >> additional bits to support Octal and Octal DDR mode. Therefore, extend >> current driver to support Octal mode. Only Octal SDR read (1-1-8)mode is >> supported for now. > > Does this your Cadence OSPI controller support 8-8-8 IO mode, if yes, > Why not directly enable 8-8-8 mode? > Yes.. IP also supports 8-8-8 DTR mode. But supporting those modes require enabling, configuring and calibrating OSPI PHY module within the IP. I am planning to do that, after moving driver over to spi-mem layer. >> Tested with mt35xu512aba Octal flash on TI's AM654 EVM. >> >> Signed-off-by: Vignesh R >> __ >> Linux MTD discussion mailing list >> http://lists.infradead.org/mailman/listinfo/linux-mtd/ > > __ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ > -- Regards Vignesh
Re: [RFC PATCH 0/5] MTD: Add Initial Hyperbus support
On 19/02/19 12:06 PM, Vignesh R wrote: [...] > > Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by > creating a UBIFS partition and writing and reading files to it. > Stress tested by writing/reading 16MB flash repeatedly at different > offsets using dd commmand. > Here is the enumeration log from dmesg: https://pastebin.ubuntu.com/p/Vd5jYQT4FH/ > HyperBus specification can be found at[1] > HyperFlash datasheet can be found at[2] > TI's HBMC controller details at[3] > > [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 > > Vignesh R (5): > mtd: cfi_cmdset_0002: Add support for polling status register > dt-bindings: mtd: Add binding documentation for Hyperbus memory > devices > mtd: Add support for Hyperbus memory devices > dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory > controller > mtd: hyperbus: Add driver for TI's Hyperbus memory controller > > .../bindings/mtd/cypress,hyperbus.txt | 6 + > .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ > MAINTAINERS | 8 + > drivers/mtd/Kconfig | 2 + > drivers/mtd/Makefile | 1 + > drivers/mtd/chips/cfi_cmdset_0002.c | 50 ++ > drivers/mtd/hyperbus/Kconfig | 23 +++ > drivers/mtd/hyperbus/Makefile | 4 + > drivers/mtd/hyperbus/core.c | 167 ++ > drivers/mtd/hyperbus/hbmc_am654.c | 105 +++ > include/linux/mtd/cfi.h | 5 + > include/linux/mtd/hyperbus.h | 73 > 12 files changed, 471 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt > create mode 100644 drivers/mtd/hyperbus/Kconfig > create mode 100644 drivers/mtd/hyperbus/Makefile > create mode 100644 drivers/mtd/hyperbus/core.c > create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c > create mode 100644 include/linux/mtd/hyperbus.h > -- Regards Vignesh
[RFC PATCH 1/5] mtd: cfi_cmdset_0002: Add support for polling status register
HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c
can be use as is. But these devices do not support DQ polling method of
determining chip ready/good status. These flashes provide Status
Register whose bits can be polled to know status of flash operation.
Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu
Extended Query version 1.5. Bit 0 of "Software Features supported" field
of CFI Primary Vendor-Specific Extended Query table indicates
presence/absence of status register and Bit 1 indicates whether or not
DQ polling is supported. Using these bits, its possible to determine
whether flash supports DQ polling or need to use Status Register.
Add support for polling status register to know device ready/status of
erase/write operations when DQ polling is not supported.
[1] https://www.cypress.com/file/213346/download
Signed-off-by: Vignesh R
---
Note: PRI extended query table size is bigger on 1.5 than on older
revision. Not sure if this causes problems on older rev. because of
reading beyond current size.
drivers/mtd/chips/cfi_cmdset_0002.c | 50 +
include/linux/mtd/cfi.h | 5 +++
2 files changed, 55 insertions(+)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
b/drivers/mtd/chips/cfi_cmdset_0002.c
index 72428b6bfc47..7a4ef0237750 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -49,6 +49,14 @@
#define SST49LF008A0x005a
#define AT49BV6416 0x00d6
+/*
+ * Bits of Status Register definition for flash devices that don't
+ * support DQ polling (Eg.: Hyperflash)
+ */
+#define CFI_SR_DRB BIT(7)
+#define CFI_SR_ESB BIT(5)
+#define CFI_SR_PSB BIT(4)
+
static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *,
u_char *);
static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *,
const u_char *);
static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t
*, const u_char *);
@@ -97,6 +105,18 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = {
.module = THIS_MODULE
};
+/*
+ * Use status register to poll for Erase/write completion when DQ is not
+ * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in
+ * CFI Primary Vendor-Specific Extended Query table 1.5
+ */
+static int cfi_use_status_reg(struct cfi_private *cfi)
+{
+ struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
+
+ return (extp->MinorVersion >= '5') &&
+ ((extp->SoftwareFeatures & 0x11) == 1);
+}
/* #define DEBUG_CFI_FEATURES */
@@ -744,8 +764,21 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info
*mtd)
*/
static int __xipram chip_ready(struct map_info *map, unsigned long addr)
{
+ struct cfi_private *cfi = map->fldrv_priv;
map_word d, t;
+ if (cfi_use_status_reg(cfi)) {
+ /*
+* For chips that support status register, check device
+* ready bit
+*/
+ cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi,
+cfi->device_type, NULL);
+ d = map_read(map, addr);
+
+ return (d.x[0] & CFI_SR_DRB);
+ }
+
d = map_read(map, addr);
t = map_read(map, addr);
@@ -769,8 +802,25 @@ static int __xipram chip_ready(struct map_info *map,
unsigned long addr)
*/
static int __xipram chip_good(struct map_info *map, unsigned long addr,
map_word expected)
{
+ struct cfi_private *cfi = map->fldrv_priv;
map_word oldd, curd;
+ if (cfi_use_status_reg(cfi)) {
+ /*
+* For chips that support status register, check device
+* ready bit and Erase/Program status bit to know if
+* operation succeeded.
+*/
+ cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi,
+cfi->device_type, NULL);
+ curd = map_read(map, addr);
+
+ if (curd.x[0] & CFI_SR_DRB)
+ return !(curd.x[0] & (CFI_SR_PSB | CFI_SR_ESB));
+
+ return 0;
+ }
+
oldd = map_read(map, addr);
curd = map_read(map, addr);
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index cbf77168658c..92ac82ac2329 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -233,6 +233,11 @@ struct cfi_pri_amdstd {
uint8_t VppMin;
uint8_t VppMax;
uint8_t TopBottom;
+ /* Below field are added from version 1.5 */
+ uint8_t ProgramSuspend;
+ uint8_t UnlockBypass;
+ uint8_t SecureSiliconSector;
+ uint8_t SoftwareFeatures;
} __packed;
/* Vendor-Specific PRI for Atmel chips (command set 0x0002) */
--
2.20.1
[RFC PATCH 0/5] MTD: Add Initial Hyperbus support
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 wrt bits per clk. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hb_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. This is an early RFC, to know if its okay to use maps framework and existing CFI compliant flash support code to support Hyperflash Also would like input on different types of HBMC master IPs out there and their programming sequences. Would appreciate any testing/review. Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by creating a UBIFS partition and writing and reading files to it. Stress tested by writing/reading 16MB flash repeatedly at different offsets using dd commmand. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] TI's HBMC controller details at[3] [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 Vignesh R (5): mtd: cfi_cmdset_0002: Add support for polling status register dt-bindings: mtd: Add binding documentation for Hyperbus memory devices mtd: Add support for Hyperbus memory devices dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller mtd: hyperbus: Add driver for TI's Hyperbus memory controller .../bindings/mtd/cypress,hyperbus.txt | 6 + .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ MAINTAINERS | 8 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 50 ++ drivers/mtd/hyperbus/Kconfig | 23 +++ drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/core.c | 167 ++ drivers/mtd/hyperbus/hbmc_am654.c | 105 +++ include/linux/mtd/cfi.h | 5 + include/linux/mtd/hyperbus.h | 73 12 files changed, 471 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/core.c create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c create mode 100644 include/linux/mtd/hyperbus.h -- 2.20.1
[RFC PATCH 3/5] mtd: Add support for Hyperbus memory devices
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 wrt bits per clk. 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 communicate with flash. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hb_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 try to detect flash as part of CFI flash probe. HyperRAM is not supported atm. 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 R --- MAINTAINERS | 7 ++ drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/hyperbus/Kconfig | 23 + drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/core.c | 167 ++ include/linux/mtd/hyperbus.h | 73 +++ 7 files changed, 277 insertions(+) create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/core.c create mode 100644 include/linux/mtd/hyperbus.h diff --git a/MAINTAINERS b/MAINTAINERS index 08bf7418a97f..0808c22807bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7143,6 +7143,13 @@ F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus +HYPERBUS SUPPORT +M: Vignesh R +S: Supported +F: drivers/mtd/hyperbus/ +F: include/linux/mtd/hyperbus.h +F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt + HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-...@lists.ozlabs.org S: Odd Fixes diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 79a8ff542883..a915ff300390 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -290,4 +290,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 58fc327a5276..04c154906631 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -35,3 +35,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 ..02c38afc5c50 --- /dev/null +++ b/drivers/mtd/hyperbus/Kconfig @@ -0,0 +1,23 @@ +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 commmunicate with + Hyperflash. See Cypress Hyperbus specification for more + details + + +if MTD_HYPERBUS + +config HBMC_AM654 + tristate "Hyperbus controller driver for AM65x SoC" + help +This is the driver for Hyperbus controller on TI's AM65x and +other SoCs + +endif # MTD_HYPERBUS + diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile new file mode 100644 index ..64e377d7f636 --- /dev/null +++ b/drivers/mtd/hyperbu
[RFC PATCH 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller
Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming
IP is pretty simple and provides direct memory mapped access to
connected Flash devices.
Add basic support for the IP without DMA. Second ChipSelect is not
supported for now.
Signed-off-by: Vignesh R
---
drivers/mtd/hyperbus/hbmc_am654.c | 105 ++
1 file changed, 105 insertions(+)
create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c
diff --git a/drivers/mtd/hyperbus/hbmc_am654.c
b/drivers/mtd/hyperbus/hbmc_am654.c
new file mode 100644
index ..1f0d2dc52f9f
--- /dev/null
+++ b/drivers/mtd/hyperbus/hbmc_am654.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+// Author: Vignesh R
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct am654_hbmc_priv {
+ struct hb_device hbdev;
+ void __iomem*regbase;
+};
+
+static int am654_hbmc_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct am654_hbmc_priv *priv;
+ struct resource *res;
+ int err;
+
+ priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (IS_ERR(res)) {
+ dev_err(>dev, "failed to get memory resource\n");
+ return -ENOENT;
+ }
+
+ priv->regbase = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->regbase)) {
+ dev_err(dev, "Cannot remap controller address.\n");
+ return PTR_ERR(priv->regbase);
+ }
+
+ pm_runtime_enable(>dev);
+ err = pm_runtime_get_sync(>dev);
+ if (err < 0) {
+ pm_runtime_put_noidle(>dev);
+ return err;
+ }
+
+ priv->hbdev.needs_calib = true;
+ priv->hbdev.dev = >dev;
+ priv->hbdev.np = of_get_next_child(dev->of_node, NULL);
+ err = hb_register_device(>hbdev);
+ if (err) {
+ dev_err(>dev, "failed to register controller\n");
+ goto err_destroy;
+ }
+
+ return 0;
+
+err_destroy:
+ hb_unregister_device(>hbdev);
+ pm_runtime_put_sync(>dev);
+ return err;
+}
+
+static int am654_hbmc_remove(struct platform_device *pdev)
+{
+ struct am654_hbmc_priv *priv = platform_get_drvdata(pdev);
+ int ret;
+
+ ret = hb_unregister_device(>hbdev);
+ pm_runtime_put_sync(>dev);
+ pm_runtime_disable(>dev);
+
+ return ret;
+}
+
+static const struct of_device_id am654_hbmc_dt_ids[] = {
+ {
+ .compatible = "ti,am654-hbmc",
+ },
+ { /* end of table */ }
+};
+
+MODULE_DEVICE_TABLE(of, am654_hbmc_dt_ids);
+
+static struct platform_driver am654_hbmc_platform_driver = {
+ .probe = am654_hbmc_probe,
+ .remove = am654_hbmc_remove,
+ .driver = {
+ .name = "hbmc-am654",
+ .of_match_table = am654_hbmc_dt_ids,
+ },
+};
+
+module_platform_driver(am654_hbmc_platform_driver);
+
+MODULE_DESCRIPTION("HBMC driver for AM654 SoC");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:hbmc-am654");
+MODULE_AUTHOR("Vignesh R ");
--
2.20.1
[RFC PATCH 4/5] dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller
Add binding documentation for TI's Hyperbus memory controller present on
AM654 SoC.
Signed-off-by: Vignesh R
---
.../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++
MAINTAINERS | 1 +
2 files changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
new file mode 100644
index ..b70fd1795fc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
@@ -0,0 +1,27 @@
+Bindings for Hyperbus Memory Controller on TI's K3 family of SoCs
+
+Required properties:
+- compatible : "ti,am654-hbmc" for AM654 SoC
+- reg : Two entries:
+ First entry pointed to the register space of HBMC controller
+ Second entry pointing to the memory map region dedicated for
+ MMIO access to attached flash devices
+- ranges : Address range allocated for each Chipselect in the MMIO space
+
+Example:
+ hbmc: hbmc@47034000 {
+ compatible = "ti,am654-hbmc";
+ reg = <0x0 0x47034000 0x0 0x100>,
+ <0x5 0x 0x1 0x000>;
+ power-domains = <_pds 55>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x5 0x 0x400>, /* CS0 - 64MB */
+<0x1 0x5 0x0400 0x400>; /* CS1 - 64MB
+
+ /* Slave flash node */
+ flash@0{
+ compatible = "cypress,hyperflash";
+ reg = <0x0 0x400>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 0808c22807bc..a9760c5e33f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7149,6 +7149,7 @@ S:Supported
F: drivers/mtd/hyperbus/
F: include/linux/mtd/hyperbus.h
F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt
+F: Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
HYPERVISOR VIRTUAL CONSOLE DRIVER
L: linuxppc-...@lists.ozlabs.org
--
2.20.1
[RFC PATCH 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices
Add DT binding documentation for Hyperbus memory devices. For now only Hyperflash is supported. Signed-off-by: Vignesh R --- Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt new file mode 100644 index ..cb408f80b868 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt @@ -0,0 +1,6 @@ +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus +specification and supports Cypress CFI specification 1.5 command set. + +Required properties: +- compatible : "cypress,hyperflash" for Hyperflash NOR chips +- reg : Address where flash's memory mapped space -- 2.20.1
Re: [PATCH][next] mtd: spi-nor: cadence-quadspi: fix spelling mistake: "Couldnt't" -> "Couldn't"
On 15/02/19 8:45 PM, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> index 56512c0368f9..792628750eec 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -1249,7 +1249,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
> struct device_node *np)
>
> ddata = of_device_get_match_data(dev);
> if (!ddata) {
> - dev_err(dev, "Couldnt't find driver data\n");
> + dev_err(dev, "Couldn't find driver data\n");
> return -EINVAL;
> }
> hwcaps.mask = ddata->hwcaps_mask;
>
Oops, my bad.. Thanks for fixing this!
--
Regards
Vignesh
[PATCH] arm64: dts: ti: k3-am65-mcu: Add ADC nodes
TI AM654 SoC has two ADC instances in the MCU domain. Add DT nodes for
the same.
Signed-off-by: Vignesh R
---
Tero,
Could you also pick up DT bindings here:
https://patchwork.kernel.org/patch/10751429/
All the Acks are in place.
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 +++
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 12
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 593f718e8fb5..6f7d2b316ded 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -57,4 +57,34 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+ tscadc0: tscadc@4020 {
+ compatible = "ti,am654-tscadc", "ti,am3359-tscadc";
+ reg = <0x0 0x4020 0x0 0x1000>;
+ interrupts = ;
+ clocks = <_clks 0 2>;
+ assigned-clocks = <_clks 0 2>;
+ assigned-clock-rates = <6000>;
+ clock-names = "adc_tsc_fck";
+
+ adc {
+ #io-channel-cells = <1>;
+ compatible = "ti,am654-adc", "ti,am3359-adc";
+ };
+ };
+
+ tscadc1: tscadc@4021 {
+ compatible = "ti,am654-tscadc", "ti,am3359-tscadc";
+ reg = <0x0 0x4021 0x0 0x1000>;
+ interrupts = ;
+ clocks = <_clks 1 2>;
+ assigned-clocks = <_clks 1 2>;
+ assigned-clock-rates = <6000>;
+ clock-names = "adc_tsc_fck";
+
+ adc {
+ #io-channel-cells = <1>;
+ compatible = "ti,am654-adc", "ti,am3359-adc";
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index e41fc3a5987b..fb6df5c8f85b 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -163,3 +163,15 @@
#size-cells= <1>;
};
};
+
+ {
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5 6 7>;
+ };
+};
+
+ {
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5 6 7>;
+ };
+};
--
2.20.1
[PATCH v6 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v6: No change Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.20.1
[PATCH v6 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Tested with AM654 EVM with MT35x512 Octal flash Changes: v5: Fix comments from by on v4. v4: Fix comments on v3 by Tudor. Rebase on top latest linux-next(all dependencies are now part of -next) v3: Rebase on top of v7 of Yogesh's series[1] v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 59 +++ 2 files changed, 48 insertions(+), 12 deletions(-) -- 2.20.1
[PATCH v6 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode. Only Octal SDR read (1-1-8)mode is supported for now.
Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
Signed-off-by: Vignesh R
---
v6: Return error when driver data is not found
drivers/mtd/spi-nor/cadence-quadspi.c | 59 +--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..c8b81e0a76cc 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -44,6 +44,12 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+/* Capabilities mask */
+#define CQSPI_BASE_HWCAPS_MASK \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
struct cqspi_st;
struct cqspi_flash_pdata {
@@ -93,6 +99,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +112,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1228,23 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+ const struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = of_device_get_match_data(dev);
+ if (!ddata) {
+ dev_err(dev, "Couldnt't find driver data\n");
+ return -EINVAL;
+ }
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1327,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ const struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1394,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1477,32 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+static const struct cqspi_driver_platdata cdns_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+};
+
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,q
Re: [PATCH v2] dt-bindings: input: ti-tsc-adc: Add new compatible for AM654 SoCs
Hi Dmitry, On 08/01/19 10:56 AM, Vignesh R wrote: > AM654 SoCs has ADC IP which is similar to AM335x, but without the > touchscreen part. Add new compatible to handle AM654 SoCs. Also, it > seems that existing compatible strings used in the kernel DTs were never > documented. So, document them now. > > Signed-off-by: Vignesh R > Reviewed-by: Rob Herring > --- If there are no comments, could you queue this bindings patch? This will help me in getting ADC DT nodes to be merged into ARM SoC tree. Regards Vignesh > v2: > Fix subject line to include subsystem name > Rebase onto v5.0-rc1 > v1: https://lkml.org/lkml/2018/11/19/313 > > .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > index b1163bf97146..aad5e34965eb 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > @@ -2,7 +2,12 @@ > ~~ > > Required properties: > +- mfd > + compatible: Should be > + "ti,am3359-tscadc" for AM335x/AM437x SoCs > + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs > - child "tsc" > + compatible: Should be "ti,am3359-tsc". > ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen > support on the platform. > ti,x-plate-resistance: X plate resistance > @@ -25,6 +30,9 @@ Required properties: > AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > XP = 0, XN = 1, YP = 2, YN = 3. > - child "adc" > + compatible: Should be > + "ti,am3359-adc" for AM335x/AM437x SoCs > + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs > ti,adc-channels: List of analog inputs available for ADC. >AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > > -- Regards Vignesh
Re: [PATCH v5 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
On 10/02/19 6:49 PM, Boris Brezillon wrote:
> On Tue, 5 Feb 2019 11:43:46 +0530
> Vignesh R wrote:
>
>>>> static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node
>>>> *np)
>>>> {
>>>> - const struct spi_nor_hwcaps hwcaps = {
>>>> - .mask = SNOR_HWCAPS_READ |
>>>> - SNOR_HWCAPS_READ_FAST |
>>>> - SNOR_HWCAPS_READ_1_1_2 |
>>>> - SNOR_HWCAPS_READ_1_1_4 |
>>>> - SNOR_HWCAPS_PP,
>>>> - };
>>>>struct platform_device *pdev = cqspi->pdev;
>>>>struct device *dev = >dev;
>>>> + const struct cqspi_driver_platdata *ddata;
>>>> + struct spi_nor_hwcaps hwcaps;
>>>>struct cqspi_flash_pdata *f_pdata;
>>>>struct spi_nor *nor;
>>>>struct mtd_info *mtd;
>>>>unsigned int cs;
>>>>int i, ret;
>>>>
>>>> + ddata = of_device_get_match_data(dev);
>>>> + if (!ddata)
>>>> + hwcaps.mask = CQSPI_BASE_HWCAPS_MASK;
>>>
>>> Now that .data is set in all cqspi_dt_ids[], maybe it's better to print a
>>> message and return an error here. But I guess it's a matter of taste, so
>>> not a
>>> show stopper.
>>
>> Since, driver data is kernel internal field, I guess there is little
>> help in printing out the error to the user when its missing. I prefer to
>> keep this as is, as basic Quad mode is supported by all versions of the IP.
>
> Well, if all compat entries have an associated platdata instance we
> don't need to support the !ddata case, right? I think enforcing the
> presence of such a platdata is actually is a sane thing to do (which
> implies returning an error when ddata is NULL).
>
Ok, will respin with a dev_err() and return -EINVAL when ddata is NULL.
--
Regards
Vignesh
Re: [PATCH] mtd: spi-nor: cadence-quadspi: write upto 8-bytes data in STIG mode
On 05/02/19 12:30 PM, Mandal, Purna Chandra wrote:
>
>
> On 04-Feb-19 7:07 PM, Vignesh R wrote:
>> Hi,
>>
>> On 03/02/19 5:50 PM, tudor.amba...@microchip.com wrote:
>>> + Vignesh
>>>
>>
>> Thanks for looping in.
>>
>>> On 01/28/2019 07:02 AM, Purna Chandra Mandal wrote:
>>>> cadence-quadspi controller allows upto eight bytes of data to
>>>> be written in software Triggered Instruction generator (STIG) mode
>>>> of operation. Lower 4 bytes are written through writedatalower and
>>>> upper 4 bytes by writedataupper register.
>>>>
>>>> This patch allows all the 8 bytes to be written.
>>>>
>>
>> Code as such looks fine. But, how was this tested? How can I trigger
>> this new code path with current linux-next? AFAICS, STIG mode write is
>> used to in nor->write_reg() path, and I dont see any nor->write_reg()
>> call with >4bytes len.
> Currently there is no linux user of write_reg() for write_len > 4byte.
>
> For volatile and non-volatile sector locking [1], we have one out of
> tree implementation and that is specific to flash chip "mt25qu02g". In
> this implementation we need additional sector address (4 byte) to be
> provided for each lock-bit write/erase operation. So total write len in
> write_reg() will be 6 bytes (=1 for opcode, 4 for sect addr, 1 for
> data). We are finalizing the patch for review.
>
> Since cadence qspi controller do support the 8-byte read/write in STIG
> mode, I have tried here to enable that in write_reg(), similar to
> read_reg().
>
Sounds good.
Reviewed-by: Vignesh R
> [1]
> https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_128mb_3v_65nm.pdf
>
>>
>>>> Signed-off-by: Purna Chandra Mandal
>>>
>>> Looks good for me:
>>> Reviewed-by: Tudor Ambarus
>>>
>>> Vignesh, can we have your R-b or T-b tag?
>>>
>>> Cheers,
>>> ta
>>>
>>>> ---
>>>>
>>>> drivers/mtd/spi-nor/cadence-quadspi.c | 15 ---
>>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> index 04cedd3a2bf6..7f78f9409ddd 100644
>>>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> @@ -418,9 +418,10 @@ static int cqspi_command_write(struct spi_nor *nor,
>>>> const u8 opcode,
>>>>void __iomem *reg_base = cqspi->iobase;
>>>>unsigned int reg;
>>>>unsigned int data;
>>>> + u32 write_len;
>>>>int ret;
>>>>
>>>> - if (n_tx > 4 || (n_tx && !txbuf)) {
>>>> + if (n_tx > CQSPI_STIG_DATA_LEN_MAX || (n_tx && !txbuf)) {
>>>>dev_err(nor->dev,
>>>>"Invalid input argument, cmdlen %d txbuf 0x%p\n",
>>>>n_tx, txbuf);
>>>> @@ -433,10 +434,18 @@ static int cqspi_command_write(struct spi_nor *nor,
>>>> const u8 opcode,
>>>>reg |= ((n_tx - 1) & CQSPI_REG_CMDCTRL_WR_BYTES_MASK)
>>>><< CQSPI_REG_CMDCTRL_WR_BYTES_LSB;
>>>>data = 0;
>>>> - memcpy(, txbuf, n_tx);
>>>> + write_len = (n_tx > 4) ? 4 : n_tx;
>>>> + memcpy(, txbuf, write_len);
>>>> + txbuf += write_len;
>>>>writel(data, reg_base + CQSPI_REG_CMDWRITEDATALOWER);
>>>> - }
>>>>
>>>> + if (n_tx > 4) {
>>>> + data = 0;
>>>> + write_len = n_tx - 4;
>>>> + memcpy(, txbuf, write_len);
>>>> + writel(data, reg_base + CQSPI_REG_CMDWRITEDATAUPPER);
>>>> + }
>>>> + }
>>>>ret = cqspi_exec_flash_cmd(cqspi, reg);
>>>>return ret;
>>>> }
>>>>
>>
--
Regards
Vignesh
Re: [PATCH v5 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Hi,
On 29/01/19 9:02 PM, tudor.amba...@microchip.com wrote:
>
>
> On 01/28/2019 07:49 AM, Vignesh R wrote:
>> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
>> It also has an integrated PHY. IP register layout is very
>> similar to existing QSPI IP except for additional bits to support Octal
>> and Octal DDR mode. Therefore, extend current driver to support Octal
>> mode. Only Octal SDR read (1-1-8)mode is supported for now.
>>
>> Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
>>
>> Signed-off-by: Vignesh R
>> Reviewed-by: Tudor Ambarus
>> ---
>>
>> v5:
>> s/cqsi_base_hwcaps_mask/CQSPI_BASE_HWCAPS_MASK/g
>> Add back cqspi_driver_platdata definition for base compatible.
>>
>> v4: Fix comments by Tudor on v3
>> v3: No changes
>> v2: Declare Octal mode capability based on compatible.
>>
>> drivers/mtd/spi-nor/cadence-quadspi.c | 58 +--
>> 1 file changed, 46 insertions(+), 12 deletions(-)
[...]
>>
>> static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
>> {
>> -const struct spi_nor_hwcaps hwcaps = {
>> -.mask = SNOR_HWCAPS_READ |
>> -SNOR_HWCAPS_READ_FAST |
>> -SNOR_HWCAPS_READ_1_1_2 |
>> -SNOR_HWCAPS_READ_1_1_4 |
>> -SNOR_HWCAPS_PP,
>> -};
>> struct platform_device *pdev = cqspi->pdev;
>> struct device *dev = >dev;
>> +const struct cqspi_driver_platdata *ddata;
>> +struct spi_nor_hwcaps hwcaps;
>> struct cqspi_flash_pdata *f_pdata;
>> struct spi_nor *nor;
>> struct mtd_info *mtd;
>> unsigned int cs;
>> int i, ret;
>>
>> +ddata = of_device_get_match_data(dev);
>> +if (!ddata)
>> +hwcaps.mask = CQSPI_BASE_HWCAPS_MASK;
>
> Now that .data is set in all cqspi_dt_ids[], maybe it's better to print a
> message and return an error here. But I guess it's a matter of taste, so not a
> show stopper.
Since, driver data is kernel internal field, I guess there is little
help in printing out the error to the user when its missing. I prefer to
keep this as is, as basic Quad mode is supported by all versions of the IP.
Regards
Vignesh
>
>> +else
>> +hwcaps.mask = ddata->hwcaps_mask;
>> +
>> /* Get flash device data */
>> for_each_available_child_of_node(dev->of_node, np) {
>> ret = of_property_read_u32(np, "reg", );
>> @@ -1310,7 +1326,7 @@ static int cqspi_probe(struct platform_device *pdev)
>> struct cqspi_st *cqspi;
>> struct resource *res;
>> struct resource *res_ahb;
>> -unsigned long data;
>> +const struct cqspi_driver_platdata *ddata;
>> int ret;
>> int irq;
>>
>> @@ -1377,8 +1393,8 @@ static int cqspi_probe(struct platform_device *pdev)
>> }
>>
>> cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
>> -data = (unsigned long)of_device_get_match_data(dev);
>> -if (data & CQSPI_NEEDS_WR_DELAY)
>> +ddata = of_device_get_match_data(dev);
>> +if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
>> cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
>> cqspi->master_ref_clk_hz);
>>
>> @@ -1460,14 +1476,32 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
>> #define CQSPI_DEV_PM_OPSNULL
>> #endif
>>
>> +static const struct cqspi_driver_platdata cdns_qspi = {
>> +.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
>> +};
>> +
>> +static const struct cqspi_driver_platdata k2g_qspi = {
>> +.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
>> +.quirks = CQSPI_NEEDS_WR_DELAY,
>> +};
>> +
>> +static const struct cqspi_driver_platdata am654_ospi = {
>> +.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK | SNOR_HWCAPS_READ_1_1_8,
>> +.quirks = CQSPI_NEEDS_WR_DELAY,
>> +};
>> +
>> static const struct of_device_id cqspi_dt_ids[] = {
>> {
>> .compatible = "cdns,qspi-nor",
>> -.data = (void *)0,
>> +.data = _qspi,
>> },
>> {
>> .compatible = "ti,k2g-qspi",
>> -.data = (void *)CQSPI_NEEDS_WR_DELAY,
>> +.data = _qspi,
>> +},
>> +{
>> +.compatible = "ti,am654-ospi",
>> +.data = _ospi,
>> },
>> { /* end of table */ }
>> };
>>
--
Regards
Vignesh
Re: [PATCH] mtd: spi-nor: cadence-quadspi: write upto 8-bytes data in STIG mode
Hi,
On 03/02/19 5:50 PM, tudor.amba...@microchip.com wrote:
> + Vignesh
>
Thanks for looping in.
> On 01/28/2019 07:02 AM, Purna Chandra Mandal wrote:
>> cadence-quadspi controller allows upto eight bytes of data to
>> be written in software Triggered Instruction generator (STIG) mode
>> of operation. Lower 4 bytes are written through writedatalower and
>> upper 4 bytes by writedataupper register.
>>
>> This patch allows all the 8 bytes to be written.
>>
Code as such looks fine. But, how was this tested? How can I trigger
this new code path with current linux-next? AFAICS, STIG mode write is
used to in nor->write_reg() path, and I dont see any nor->write_reg()
call with >4bytes len.
>> Signed-off-by: Purna Chandra Mandal
>
> Looks good for me:
> Reviewed-by: Tudor Ambarus
>
> Vignesh, can we have your R-b or T-b tag?
>
> Cheers,
> ta
>
>> ---
>>
>> drivers/mtd/spi-nor/cadence-quadspi.c | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
>> b/drivers/mtd/spi-nor/cadence-quadspi.c
>> index 04cedd3a2bf6..7f78f9409ddd 100644
>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>> @@ -418,9 +418,10 @@ static int cqspi_command_write(struct spi_nor *nor,
>> const u8 opcode,
>> void __iomem *reg_base = cqspi->iobase;
>> unsigned int reg;
>> unsigned int data;
>> +u32 write_len;
>> int ret;
>>
>> -if (n_tx > 4 || (n_tx && !txbuf)) {
>> +if (n_tx > CQSPI_STIG_DATA_LEN_MAX || (n_tx && !txbuf)) {
>> dev_err(nor->dev,
>> "Invalid input argument, cmdlen %d txbuf 0x%p\n",
>> n_tx, txbuf);
>> @@ -433,10 +434,18 @@ static int cqspi_command_write(struct spi_nor *nor,
>> const u8 opcode,
>> reg |= ((n_tx - 1) & CQSPI_REG_CMDCTRL_WR_BYTES_MASK)
>> << CQSPI_REG_CMDCTRL_WR_BYTES_LSB;
>> data = 0;
>> -memcpy(, txbuf, n_tx);
>> +write_len = (n_tx > 4) ? 4 : n_tx;
>> +memcpy(, txbuf, write_len);
>> +txbuf += write_len;
>> writel(data, reg_base + CQSPI_REG_CMDWRITEDATALOWER);
>> -}
>>
>> +if (n_tx > 4) {
>> +data = 0;
>> +write_len = n_tx - 4;
>> +memcpy(, txbuf, write_len);
>> +writel(data, reg_base + CQSPI_REG_CMDWRITEDATAUPPER);
>> +}
>> +}
>> ret = cqspi_exec_flash_cmd(cqspi, reg);
>> return ret;
>> }
>>
--
Regards
Vignesh
[PATCH] spi: ti-qspi: Fix mmap read when more than one CS in use
Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has
has got order of parameter wrong when calling regmap_update_bits() to
select CS for mmap access. Mask and value arguments are interchanged.
Code will work on a system with single slave, but fails when more than
one CS is in use. Fix this by correcting the order of parameters when
calling regmap_update_bits().
Fixes: 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support")
Cc: sta...@vger.kernel.org
Signed-off-by: Vignesh R
---
drivers/spi/spi-ti-qspi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 5f19016bbf10..b9fb6493cd6b 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -490,8 +490,8 @@ static void ti_qspi_enable_memory_map(struct spi_device
*spi)
ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base) {
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
- MEM_CS_EN(spi->chip_select),
- MEM_CS_MASK);
+ MEM_CS_MASK,
+ MEM_CS_EN(spi->chip_select));
}
qspi->mmap_enabled = true;
}
@@ -503,7 +503,7 @@ static void ti_qspi_disable_memory_map(struct spi_device
*spi)
ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base)
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
- 0, MEM_CS_MASK);
+ MEM_CS_MASK, 0);
qspi->mmap_enabled = false;
}
--
2.20.1
[PATCH v5 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Tested with AM654 EVM with MT35x512 Octal flash Changes: v5: Fix comments from by on v4. v4: Fix comments on v3 by Tudor. Rebase on top latest linux-next(all dependencies are now part of -next) v3: Rebase on top of v7 of Yogesh's series[1] v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 58 +++ 2 files changed, 47 insertions(+), 12 deletions(-) -- 2.20.1
[PATCH v5 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode. Only Octal SDR read (1-1-8)mode is supported for now.
Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
Signed-off-by: Vignesh R
Reviewed-by: Tudor Ambarus
---
v5:
s/cqsi_base_hwcaps_mask/CQSPI_BASE_HWCAPS_MASK/g
Add back cqspi_driver_platdata definition for base compatible.
v4: Fix comments by Tudor on v3
v3: No changes
v2: Declare Octal mode capability based on compatible.
drivers/mtd/spi-nor/cadence-quadspi.c | 58 +--
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..c8113ebe44fd 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -44,6 +44,12 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+/* Capabilities mask */
+#define CQSPI_BASE_HWCAPS_MASK \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
struct cqspi_st;
struct cqspi_flash_pdata {
@@ -93,6 +99,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +112,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1228,22 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+ const struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = of_device_get_match_data(dev);
+ if (!ddata)
+ hwcaps.mask = CQSPI_BASE_HWCAPS_MASK;
+ else
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1326,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ const struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1393,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1476,32 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+static const struct cqspi_driver_platdata cdns_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+};
+
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQ
[PATCH v5 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.20.1
Re: [PATCH v4 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
On 23-Jan-19 2:15 PM, Boris Brezillon wrote:
> On Tue, 22 Jan 2019 12:11:37 +0530
> Vignesh R wrote:
>
>> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
>> It also has an integrated PHY. IP register layout is very
>> similar to existing QSPI IP except for additional bits to support Octal
>> and Octal DDR mode. Therefore, extend current driver to support Octal
>> mode. Only Octal SDR read (1-1-8)mode is supported for now.
>>
>> Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
>>
>> Signed-off-by: Vignesh R
>> ---
>>
>> v4: Fix comments by Tudor on v3
>> v3: No changes
>> v2: Declare Octal mode capability based on compatible.
>>
>> drivers/mtd/spi-nor/cadence-quadspi.c | 53 +--
>> 1 file changed, 41 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
>> b/drivers/mtd/spi-nor/cadence-quadspi.c
>> index 04cedd3a2bf6..2091addc45a3 100644
>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>> @@ -44,6 +44,12 @@
>> /* Quirks */
>> #define CQSPI_NEEDS_WR_DELAYBIT(0)
>>
>> +/* Capabilities mask */
>> +#define cqspi_base_hwcaps_mask \
>
> Nit: we usually use upper cases for such definitions.
>
Will fix.
>> +(SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
>> +SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
>> +SNOR_HWCAPS_PP)
>> +
>> struct cqspi_st;
>>
>> struct cqspi_flash_pdata {
>> @@ -93,6 +99,11 @@ struct cqspi_st {
>> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>> };
>>
>> +struct cqspi_driver_platdata {
>> +u32 hwcaps_mask;
>> +u8 quirks;
>> +};
>> +
>> /* Operation timeout value */
>> #define CQSPI_TIMEOUT_MS500
>> #define CQSPI_READ_TIMEOUT_MS 10
>> @@ -101,6 +112,7 @@ struct cqspi_st {
>> #define CQSPI_INST_TYPE_SINGLE 0
>> #define CQSPI_INST_TYPE_DUAL1
>> #define CQSPI_INST_TYPE_QUAD2
>> +#define CQSPI_INST_TYPE_OCTAL 3
>>
>> #define CQSPI_DUMMY_CLKS_PER_BYTE 8
>> #define CQSPI_DUMMY_BYTES_MAX 4
>> @@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
>> int read)
>> case SNOR_PROTO_1_1_4:
>> f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
>> break;
>> +case SNOR_PROTO_1_1_8:
>> +f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
>> +break;
>> default:
>> return -EINVAL;
>> }
>> @@ -1213,21 +1228,22 @@ static void cqspi_request_mmap_dma(struct cqspi_st
>> *cqspi)
>>
>> static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
>> {
>> -const struct spi_nor_hwcaps hwcaps = {
>> -.mask = SNOR_HWCAPS_READ |
>> -SNOR_HWCAPS_READ_FAST |
>> -SNOR_HWCAPS_READ_1_1_2 |
>> -SNOR_HWCAPS_READ_1_1_4 |
>> -SNOR_HWCAPS_PP,
>> -};
>> struct platform_device *pdev = cqspi->pdev;
>> struct device *dev = >dev;
>> +const struct cqspi_driver_platdata *ddata;
>> +struct spi_nor_hwcaps hwcaps;
>> struct cqspi_flash_pdata *f_pdata;
>> struct spi_nor *nor;
>> struct mtd_info *mtd;
>> unsigned int cs;
>> int i, ret;
>>
>> +ddata = of_device_get_match_data(dev);
>> +if (!ddata)
>> +hwcaps.mask = cqspi_base_hwcaps_mask;
>> +else
>> +hwcaps.mask = ddata->hwcaps_mask;
>> +
>> /* Get flash device data */
>> for_each_available_child_of_node(dev->of_node, np) {
>> ret = of_property_read_u32(np, "reg", );
>> @@ -1310,7 +1326,7 @@ static int cqspi_probe(struct platform_device *pdev)
>> struct cqspi_st *cqspi;
>> struct resource *res;
>> struct resource *res_ahb;
>> -unsigned long data;
>> +const struct cqspi_driver_platdata *ddata;
>> int ret;
>> int irq;
>>
>> @@ -1377,8 +1393,8 @@ static int cqspi_probe(struct platform_device *pdev)
>> }
>>
>> cqspi->master_ref_clk_hz = clk_get
[PATCH v4 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode. Only Octal SDR read (1-1-8)mode is supported for now.
Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
Signed-off-by: Vignesh R
---
v4: Fix comments by Tudor on v3
v3: No changes
v2: Declare Octal mode capability based on compatible.
drivers/mtd/spi-nor/cadence-quadspi.c | 53 +--
1 file changed, 41 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..2091addc45a3 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -44,6 +44,12 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+/* Capabilities mask */
+#define cqspi_base_hwcaps_mask \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
struct cqspi_st;
struct cqspi_flash_pdata {
@@ -93,6 +99,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +112,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1228,22 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+ const struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = of_device_get_match_data(dev);
+ if (!ddata)
+ hwcaps.mask = cqspi_base_hwcaps_mask;
+ else
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1326,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ const struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1393,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1476,27 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
- .data = (void *)0,
},
{
.compatible = "ti,k2g-qspi&quo
[PATCH v4 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v4: No changes Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.20.1
[PATCH v4 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Tested with AM654 EVM with MT35x512 Octal flash Changes: v4: Fix comments on v3 by Tudor. Rebase on top latest linux-next(all dependencies are now part of -next) v3: Rebase on top of v7 of Yogesh's series[1] v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 53 ++- 2 files changed, 42 insertions(+), 12 deletions(-) -- 2.20.1
Re: [PATCH v3 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Hi, Tudor,
On 20/01/19 8:26 PM, tudor.amba...@microchip.com wrote:
> Hi, Vignesh,
>
> On 01/16/2019 12:30 PM, Vignesh R wrote:
>> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
>> It also has an integrated PHY. IP register layout is very
>> similar to existing QSPI IP except for additional bits to support Octal
>> and Octal DDR mode. Therefore, extend current driver to support Octal
>> mode.
>>
>> Signed-off-by: Vignesh R
>> ---
>> v3: No changes
>>
>> v2:
>> Declare Octal mode capability based on compatible.
>>
>> drivers/mtd/spi-nor/cadence-quadspi.c | 54 +--
>> 1 file changed, 42 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
>> b/drivers/mtd/spi-nor/cadence-quadspi.c
>> index 04cedd3a2bf6..31ed50f78972 100644
>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>> @@ -93,6 +93,11 @@ struct cqspi_st {
>> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>> };
>>
>> +struct cqspi_driver_platdata {
>> +u32 hwcaps_mask;
>> +u8 quirks;
>> +};
>> +
>> /* Operation timeout value */
>> #define CQSPI_TIMEOUT_MS500
>> #define CQSPI_READ_TIMEOUT_MS 10
>> @@ -101,6 +106,7 @@ struct cqspi_st {
>> #define CQSPI_INST_TYPE_SINGLE 0
>> #define CQSPI_INST_TYPE_DUAL1
>> #define CQSPI_INST_TYPE_QUAD2
>> +#define CQSPI_INST_TYPE_OCTAL 3
>>
>> #define CQSPI_DUMMY_CLKS_PER_BYTE 8
>> #define CQSPI_DUMMY_BYTES_MAX 4
>> @@ -911,6 +917,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
>> int read)
>> case SNOR_PROTO_1_1_4:
>> f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
>> break;
>> +case SNOR_PROTO_1_1_8:
>> +f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
>> +break;
>> default:
>> return -EINVAL;
>> }
>> @@ -1213,21 +1222,19 @@ static void cqspi_request_mmap_dma(struct cqspi_st
>> *cqspi)
>>
>> static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
>> {
>> -const struct spi_nor_hwcaps hwcaps = {
>> -.mask = SNOR_HWCAPS_READ |
>> -SNOR_HWCAPS_READ_FAST |
>> -SNOR_HWCAPS_READ_1_1_2 |
>> -SNOR_HWCAPS_READ_1_1_4 |
>> -SNOR_HWCAPS_PP,
>> -};
>> struct platform_device *pdev = cqspi->pdev;
>> struct device *dev = >dev;
>> +struct cqspi_driver_platdata *ddata;
>
> const struct cqspi_driver_platdata *ddata;
>
>> +struct spi_nor_hwcaps hwcaps;
>> struct cqspi_flash_pdata *f_pdata;
>> struct spi_nor *nor;
>> struct mtd_info *mtd;
>> unsigned int cs;
>> int i, ret;
>>
>> +ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
>
> You forgot to check for NULL. Also, I would expect an implicit type cast, you
> can drop the explicit cast.
>
>> +hwcaps.mask = ddata->hwcaps_mask;
>> +
>> /* Get flash device data */
>> for_each_available_child_of_node(dev->of_node, np) {
>> ret = of_property_read_u32(np, "reg", );
>> @@ -1310,7 +1317,7 @@ static int cqspi_probe(struct platform_device *pdev)
>> struct cqspi_st *cqspi;
>> struct resource *res;
>> struct resource *res_ahb;
>> -unsigned long data;
>> +struct cqspi_driver_platdata *ddata;
>
> const struct cqspi_driver_platdata *ddata;
>
>> int ret;
>> int irq;
>>
>> @@ -1377,8 +1384,8 @@ static int cqspi_probe(struct platform_device *pdev)
>> }
>>
>> cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
>> -data = (unsigned long)of_device_get_match_data(dev);
>> -if (data & CQSPI_NEEDS_WR_DELAY)
>> +ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
>
> I would expect an implicit type cast, you can drop the explicit cast.
>
>> +if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
>> cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
>> cqspi->master_ref_clk_hz);
>&
Re: [PATCH v3 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
On 20/01/19 8:58 PM, tudor.amba...@microchip.com wrote: > Vignesh, > > On 01/20/2019 04:56 PM, tudor.amba...@microchip.com wrote: >> Looks good. > > one more thing: in cqspi_read_setup() I see that the dummy cycles are adjusted > if (f_pdata->inst_width != CQSPI_INST_TYPE_QUAD). > > Should you adjust the dummy cycles for octo too? Driver does not claim support for SNOR_HWCAPS_PP_4_4_4 mode or SNOR_HWCAPS_PP_8_8_8 mode. Therefore inst_width is always be CQSPI_INST_TYPE_SINGLE (cqspi_set_protocol() always sets inst_width and addr_width to CQSPI_INST_TYPE_SINGLE). Code to support 4_4_4 or 8_8_8 mode is incomplete in the driver. Also, using mode bits to satisfy dummy clk cycles does not seem right. My guess is driver is broken, if inst_width is indeed CQSPI_INST_TYPE_QUAD as we end up sending additional 8 dummy clock cycles over what is asked in nor->read_dummy. I will plan to fix these as part of moving driver over to spi-mem. But above code should not impact 1-1-8 mode support. > I tried to find a datasheet for the controller, without success though ... > You can find Octal SPI controller datasheet in AM65x SoC TRM here: http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Page 9449: 12.3.2 Octal Serial Peripheral Interface (OSPI) -- Regards Vignesh
[PATCH v3 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v3: No changes Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.20.1
[PATCH v3 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode.
Signed-off-by: Vignesh R
---
v3: No changes
v2:
Declare Octal mode capability based on compatible.
drivers/mtd/spi-nor/cadence-quadspi.c | 54 +--
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..31ed50f78972 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -93,6 +93,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +106,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +917,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1222,19 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+ struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1317,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1384,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1467,37 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+#define cqspi_base_hwcaps_mask \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
+static const struct cqspi_driver_platdata cdns_qspi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask,
+};
+
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
- .data = (void *)0,
+ .data = (void *)_qspi,
},
{
.compatible = "ti,k2g-qspi",
- .data = (void *)CQSPI_NEEDS_WR_DELAY,
+ .data = (void *)_qspi,
+ },
+ {
+ .compatible = "ti,am654-ospi",
+ .data = (void *)_ospi,
},
{ /* end of table */ }
};
--
2.20.1
[PATCH v3 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Based on top of [1][2] that add Octal mode support in spi-nor core: [1] https://patchwork.ozlabs.org/patch/1025081/ [2] https://patchwork.ozlabs.org/patch/1025082/ Changes: v3: Rebase on top of v7 of Yogesh's series[1] v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 54 ++- 2 files changed, 43 insertions(+), 12 deletions(-) -- 2.20.1
[PATCH] spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch
Commit b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word
length")
broke SPI transfers where bits_per_word != 8. This is because of
mimsatch between McSPI FIFO level event trigger size (SPI word length) and
DMA request size(word length * maxburst). This leads to data
corruption, lockup and errors like:
spi1.0: EOW timed out
Fix this by setting DMA maxburst size to 1 so that
McSPI FIFO level event trigger size matches DMA request size.
Fixes: b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word
length")
Cc: sta...@vger.kernel.org
Reported-by: David Lechner
Tested-by: David Lechner
Signed-off-by: Vignesh R
---
drivers/spi/spi-omap2-mcspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 2fd8881fcd65..8be304379628 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -623,8 +623,8 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
cfg.dst_addr = cs->phys + OMAP2_MCSPI_TX0;
cfg.src_addr_width = width;
cfg.dst_addr_width = width;
- cfg.src_maxburst = es;
- cfg.dst_maxburst = es;
+ cfg.src_maxburst = 1;
+ cfg.dst_maxburst = 1;
rx = xfer->rx_buf;
tx = xfer->tx_buf;
--
2.20.1
Re: [PATCH] Revert "spi: omap2-mcspi: Set FIFO DMA trigger level to word length"
On 14/01/19 2:19 AM, David Lechner wrote:
> This reverts commit b682cffa3ac6d9d9e16e9b413c45caee3b391fab.
>
> That commit breaks displays using tinydrm drivers, such as ili9225.
>
> It causes corruption in the image that is displayed (it looks like only
> 1/2 of the framebuffer data is sent, the other half of the display
> remains blank.)
>
> The following error appears multiple times:
>
> ili9225 spi1.0: EOW timed out
>
> Eventually, the system locks up without any additional errors.
>
Oops, that's unfortunate. I see ili9225 is using bits_per_word = 16.
I believe commit b682cffa3ac6d9d broke spi_transfers where
bits_per_word anything other than 8 bits.
I don't have ili9225 HW but was able emulate this condition using a SPI
flash as slave on AM335x and successfully reproduced the issue. Could
you test if this diff[1] helps in fixing the regression without needing
to revert commit b682cffa3ac6d9d?
If below diff does not help, then could you post logs of types of
spi_transfers being queued by ili9225 driver? I guess you can dump them
by enabling DEBUG option in tinydrm-helpers.c.
Also which TI SoC are you using?
Sorry for the trouble!
[1]:
Adjust maxburst size of DMA xfer according to the DMA trigger level and word
length
instead of just word length
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 2fd8881fcd65..6b7edcff0e6b 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -623,8 +623,8 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
cfg.dst_addr = cs->phys + OMAP2_MCSPI_TX0;
cfg.src_addr_width = width;
cfg.dst_addr_width = width;
- cfg.src_maxburst = es;
- cfg.dst_maxburst = es;
+ cfg.src_maxburst = width / es;
+ cfg.dst_maxburst = width / es;
rx = xfer->rx_buf;
tx = xfer->tx_buf;
--
Regards
Vignesh
> Cc: Vignesh R
> Signed-off-by: David Lechner
> ---
> drivers/spi/spi-omap2-mcspi.c | 26 +++---
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 2fd8881fcd65..5a3854ff2e08 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -306,7 +306,7 @@ static void omap2_mcspi_set_fifo(const struct spi_device
> *spi,
> struct omap2_mcspi_cs *cs = spi->controller_state;
> struct omap2_mcspi *mcspi;
> unsigned int wcnt;
> - int max_fifo_depth, bytes_per_word;
> + int max_fifo_depth, fifo_depth, bytes_per_word;
> u32 chconf, xferlevel;
>
> mcspi = spi_master_get_devdata(master);
> @@ -322,6 +322,10 @@ static void omap2_mcspi_set_fifo(const struct spi_device
> *spi,
> else
> max_fifo_depth = OMAP2_MCSPI_MAX_FIFODEPTH;
>
> + fifo_depth = gcd(t->len, max_fifo_depth);
> + if (fifo_depth < 2 || fifo_depth % bytes_per_word != 0)
> + goto disable_fifo;
> +
> wcnt = t->len / bytes_per_word;
> if (wcnt > OMAP2_MCSPI_MAX_FIFOWCNT)
> goto disable_fifo;
> @@ -329,17 +333,16 @@ static void omap2_mcspi_set_fifo(const struct
> spi_device *spi,
> xferlevel = wcnt << 16;
> if (t->rx_buf != NULL) {
> chconf |= OMAP2_MCSPI_CHCONF_FFER;
> - xferlevel |= (bytes_per_word - 1) << 8;
> + xferlevel |= (fifo_depth - 1) << 8;
> }
> -
> if (t->tx_buf != NULL) {
> chconf |= OMAP2_MCSPI_CHCONF_FFET;
> - xferlevel |= bytes_per_word - 1;
> + xferlevel |= fifo_depth - 1;
> }
>
> mcspi_write_reg(master, OMAP2_MCSPI_XFERLEVEL, xferlevel);
> mcspi_write_chconf0(spi, chconf);
> - mcspi->fifo_depth = max_fifo_depth;
> + mcspi->fifo_depth = fifo_depth;
>
> return;
> }
> @@ -598,6 +601,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
> spi_transfer *xfer)
> struct dma_slave_config cfg;
> enum dma_slave_buswidth width;
> unsigned es;
> + u32 burst;
> void __iomem*chstat_reg;
> void __iomem*irqstat_reg;
> int wait_res;
> @@ -617,14 +621,22 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
> spi_transfer *xfer)
> }
>
> count = xfer->len;
> + burst = 1;
> +
> + if (mcspi->fifo_depth > 0) {
> + if (count > mcspi->fifo_depth)
> +
Re: [PATCH 1/3] serial: 8250_omap: Drop check for of_node
On 10-Jan-19 5:37 PM, Sebastian Reichel wrote: > Hi, > > On Wed, Jan 09, 2019 at 01:44:03PM -0800, Tony Lindgren wrote: >> * Vignesh R [190109 09:11]: >>> 8250_omap is DT only driver so dev->of_node always exists. Drop check >>> for existence of valid dev->of_node to simplify omap8250_probe(). >> >> That part seems safe to me now. >> >>> --- a/drivers/tty/serial/8250/8250_omap.c >>> +++ b/drivers/tty/serial/8250/8250_omap.c >> ... >>> - const struct of_device_id *id; >>> - >>> - ret = of_alias_get_id(pdev->dev.of_node, "serial"); >>> - >>> - of_property_read_u32(pdev->dev.of_node, "clock-frequency", >>> -); >>> - priv->wakeirq = irq_of_parse_and_map(pdev->dev.of_node, 1); >>> - >>> - id = of_match_device(of_match_ptr(omap8250_dt_ids), >dev); >>> - if (id && id->data) >>> - priv->habit |= *(u8 *)id->data; >> >> But this part it seems we still need to keep around >> as we still have lots of clock-frequency references >> in the *.dtsi files. Or am I missing something? > > It's re-added a couple of lines later. Only the indent was removed. > That's right. You beat me to it. Thanks :) Regards Vignesh
[PATCH 2/3] dt-bindings: serial: omap_serial: add clocks entry
Document clocks property used to pass phandle to functional clk. Signed-off-by: Vignesh R --- Documentation/devicetree/bindings/serial/omap_serial.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index c35d5ece1156..0a9b5444f4e6 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -22,6 +22,8 @@ Optional properties: - dma-names : "rx" for receive channel, "tx" for transmit channel. - rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt - rs485-rts-active-high: drive RTS high when sending (default is low). +- clocks: phandle to the functional clock as per + Documentation/devicetree/bindings/clock/clock-bindings.txt Example: -- 2.20.1
[PATCH 3/3] serial: 8250_omap: Use clk_get_rate() to obtain fclk frequency
8250_omap driver uses clock-frequency DT property to obtain functional
clk frequency. This is not ideal as users need to calculate functional
clk frequency offline and populate it in DT.
Therefore add support to obtain functional clock frequency using clk
APIs when clock-frequency DT property is not defined.
Suggested-by: Lokesh Vutla
Signed-off-by: Vignesh R
---
drivers/tty/serial/8250/8250_omap.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index a74126569785..0a8316632d75 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -12,6 +12,7 @@
#define SUPPORT_SYSRQ
#endif
+#include
#include
#include
#include
@@ -1203,7 +1204,18 @@ static int omap8250_probe(struct platform_device *pdev)
}
up.port.line = ret;
- of_property_read_u32(np, "clock-frequency", );
+ if (of_property_read_u32(np, "clock-frequency", )) {
+ struct clk *clk;
+
+ clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(clk)) {
+ if (PTR_ERR(clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ } else {
+ up.port.uartclk = clk_get_rate(clk);
+ }
+ }
+
priv->wakeirq = irq_of_parse_and_map(np, 1);
id = of_match_device(of_match_ptr(omap8250_dt_ids), >dev);
--
2.20.1
[PATCH 1/3] serial: 8250_omap: Drop check for of_node
8250_omap is DT only driver so dev->of_node always exists. Drop check
for existence of valid dev->of_node to simplify omap8250_probe().
Signed-off-by: Vignesh R
---
drivers/tty/serial/8250/8250_omap.c | 63 +
1 file changed, 28 insertions(+), 35 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index ad7ba7d0f28d..a74126569785 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1134,10 +1134,12 @@ static int omap8250_probe(struct platform_device *pdev)
{
struct resource *regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ struct device_node *np = pdev->dev.of_node;
struct omap8250_priv *priv;
struct uart_8250_port up;
int ret;
void __iomem *membase;
+ const struct of_device_id *id;
if (!regs || !irq) {
dev_err(>dev, "missing registers or irq\n");
@@ -1194,27 +1196,20 @@ static int omap8250_probe(struct platform_device *pdev)
up.port.unthrottle = omap_8250_unthrottle;
up.port.rs485_config = omap_8250_rs485_config;
- if (pdev->dev.of_node) {
- const struct of_device_id *id;
-
- ret = of_alias_get_id(pdev->dev.of_node, "serial");
-
- of_property_read_u32(pdev->dev.of_node, "clock-frequency",
-);
- priv->wakeirq = irq_of_parse_and_map(pdev->dev.of_node, 1);
-
- id = of_match_device(of_match_ptr(omap8250_dt_ids), >dev);
- if (id && id->data)
- priv->habit |= *(u8 *)id->data;
- } else {
- ret = pdev->id;
- }
+ ret = of_alias_get_id(np, "serial");
if (ret < 0) {
- dev_err(>dev, "failed to get alias/pdev id\n");
+ dev_err(>dev, "failed to get alias\n");
return ret;
}
up.port.line = ret;
+ of_property_read_u32(np, "clock-frequency", );
+ priv->wakeirq = irq_of_parse_and_map(np, 1);
+
+ id = of_match_device(of_match_ptr(omap8250_dt_ids), >dev);
+ if (id && id->data)
+ priv->habit |= *(u8 *)id->data;
+
if (!up.port.uartclk) {
up.port.uartclk = DEFAULT_CLK_SPEED;
dev_warn(>dev,
@@ -1242,25 +1237,23 @@ static int omap8250_probe(struct platform_device *pdev)
omap_serial_fill_features_erratas(, priv);
up.port.handle_irq = omap8250_no_handle_irq;
#ifdef CONFIG_SERIAL_8250_DMA
- if (pdev->dev.of_node) {
- /*
-* Oh DMA support. If there are no DMA properties in the DT then
-* we will fall back to a generic DMA channel which does not
-* really work here. To ensure that we do not get a generic DMA
-* channel assigned, we have the the_no_dma_filter_fn() here.
-* To avoid "failed to request DMA" messages we check for DMA
-* properties in DT.
-*/
- ret = of_property_count_strings(pdev->dev.of_node, "dma-names");
- if (ret == 2) {
- up.dma = >omap8250_dma;
- priv->omap8250_dma.fn = the_no_dma_filter_fn;
- priv->omap8250_dma.tx_dma = omap_8250_tx_dma;
- priv->omap8250_dma.rx_dma = omap_8250_rx_dma;
- priv->omap8250_dma.rx_size = RX_TRIGGER;
- priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
- priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
- }
+ /*
+* Oh DMA support. If there are no DMA properties in the DT then
+* we will fall back to a generic DMA channel which does not
+* really work here. To ensure that we do not get a generic DMA
+* channel assigned, we have the the_no_dma_filter_fn() here.
+* To avoid "failed to request DMA" messages we check for DMA
+* properties in DT.
+*/
+ ret = of_property_count_strings(np, "dma-names");
+ if (ret == 2) {
+ up.dma = >omap8250_dma;
+ priv->omap8250_dma.fn = the_no_dma_filter_fn;
+ priv->omap8250_dma.tx_dma = omap_8250_tx_dma;
+ priv->omap8250_dma.rx_dma = omap_8250_rx_dma;
+ priv->omap8250_dma.rx_size = RX_TRIGGER;
+ priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
+ priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
}
#endif
ret = serial8250_register_8250_port();
--
2.20.1
[PATCH 0/3] 8250_omap: use clk APIs to get fclk freqeuncy
This series adds support obtain clk frequency of functional clk via clocks phandle instead of hard coding it in DT as part of clock-frequency DT parameter. This eliminates need to calculate frequency offline and populate it. Vignesh R (3): serial: 8250_omap: Drop check for of_node dt-bindings: serial: omap_serial: add clocks entry serial: 8250_omap: Use clk_get_rate() to obtain fclk frequency .../bindings/serial/omap_serial.txt | 2 + drivers/tty/serial/8250/8250_omap.c | 75 ++- 2 files changed, 42 insertions(+), 35 deletions(-) -- 2.20.1
[PATCH v2] dt-bindings: input: ti-tsc-adc: Add new compatible for AM654 SoCs
AM654 SoCs has ADC IP which is similar to AM335x, but without the touchscreen part. Add new compatible to handle AM654 SoCs. Also, it seems that existing compatible strings used in the kernel DTs were never documented. So, document them now. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v2: Fix subject line to include subsystem name Rebase onto v5.0-rc1 v1: https://lkml.org/lkml/2018/11/19/313 .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt index b1163bf97146..aad5e34965eb 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt @@ -2,7 +2,12 @@ ~~ Required properties: +- mfd + compatible: Should be + "ti,am3359-tscadc" for AM335x/AM437x SoCs + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs - child "tsc" + compatible: Should be "ti,am3359-tsc". ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen support on the platform. ti,x-plate-resistance: X plate resistance @@ -25,6 +30,9 @@ Required properties: AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. XP = 0, XN = 1, YP = 2, YN = 3. - child "adc" + compatible: Should be + "ti,am3359-adc" for AM335x/AM437x SoCs + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs ti,adc-channels: List of analog inputs available for ADC. AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. -- 2.20.1
Re: [PATCH v6 0/7] spi: add support for octal mode
Hi, On 20/12/18 11:02 AM, Yogesh Narayan Gaur wrote: [...] >>> Yogesh Gaur (7): >>> spi: add support for octal mode I/O data transfer >>> spi: spi-mem: add support for octal mode I/O data transfer >> >> >> These two patches are already merged and is now part of linux-next[1]. >> Its preferred to send patches based on top of latest linux-next so as to >> avoid >> resending patches that have already been picked up by the maintainer. >> >> [1] >> commit 6b03061f882de49b83ccf44beb3a12c920a2da1b >> Author: Yogesh Narayan Gaur >> Date: Mon Dec 3 08:39:06 2018 + >> >> spi: add support for octal mode I/O data transfer >> >> commit b12a084c8729ef423089bb9a5a143eed39cd94e7 >> Author: Yogesh Narayan Gaur >> Date: Mon Dec 3 08:39:12 2018 + >> >> spi: spi-mem: add support for octal mode I/O data transfer >> >> > I have checked on repo "git://git.infradead.org/linux-mtd.git" on branch > "spi-nor/next" and in that kernel version is 4.20.-rc5. > In this repo above 2 patches are not present and hence has send the patches > by moving to top of this repo. > Those patches are applied to spi tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/log/?h=for-next > Can you please let me know the repo of linux-next and branch to use. > The linux-next tree is the holding area for patches aimed at the next kernel merge window. This tree includes spi-nor/next as part of mtd/next as well as many other subsystem specific -next trees: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git branch: master Regards Vignesh > -- > Regards > Yogesh Gaur > >> Regards >> Vignesh >> >>> mtd: spi-nor: add opcodes for octal Read/Write commands >>> mtd: spi-nor: add octal read flag for flash mt35xu512aba >>> mtd: m25p80: add support of octal mode I/O transfer >>> spi: nxp-fspi: add octal mode flag bit for octal support >>> arm64: dts: lx2160a: update fspi node >>> >>> Changes for v6: >>> - Correct S-o-b tag with full author name as 'Yogesh Narayan Gaur'. >>> - Rebase on top of v4.20-rc5. >>> Changes for v5: >>> - Modified string 'octo' as 'octal' in all patches. >>> Changes for v4: >>> - Rebase on top of v4.20-rc2. >>> - Modify octo entries enum value in spi.h. >>> Changes for v3: >>> - Add octo mode support in spi_setup(). >>> - Rename all patches with 'octal' string modified as 'octo'. >>> Changes for v2: >>> - Incorporated review comments of Boris and Vignesh. >>> >>> Yogesh Gaur (7): >>> spi: add support for octal mode I/O data transfer >>> spi: spi-mem: add support for octal mode I/O data transfer >>> mtd: spi-nor: add opcodes for octal Read/Write commands >>> mtd: spi-nor: add octal read flag for flash mt35xu512aba >>> mtd: m25p80: add support of octal mode I/O transfer >>> spi: nxp-fspi: add octal mode flag bit for octal support >>> arm64: dts: lx2160a: update fspi node >>> >>> arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 >>> drivers/mtd/devices/m25p80.c | 9 - >>> drivers/mtd/spi-nor/spi-nor.c | 19 --- >>> drivers/spi/spi-mem.c | 9 - >>> drivers/spi/spi-nxp-fspi.c| 4 ++-- >>> drivers/spi/spi.c | 12 ++-- >>> include/linux/mtd/spi-nor.h | 16 >>> include/linux/spi/spi.h | 4 +++- >>> 8 files changed, 63 insertions(+), 14 deletions(-) >>> >> >> -- >> Regards >> Vignesh
Re: [PATCH v6 0/7] spi: add support for octal mode
Hi, On 19/12/18 3:41 PM, Yogesh Narayan Gaur wrote: > Add support for octal mode IO data transfer. > Micron flash, mt35xu512aba, supports octal mode data transfer and > NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx). > > Patch series > * Add support for octal mode flags and parsing of same in spi driver. > * Add parsing logic for spi-mem framework and m25p80.c device file. > * Add opcodes for octal I/O commands in spi-nor framework, Read and Write > proto for (1-1-8/1-8-8) mode. > Opcodes are added as per octal data IO commands required for mt35xu512aba > [1] flash. > * Add mode bit required for octal mode in nxp-fspi driver [2]. > * Define binding property 'spi-rx/tx-bus-width' for LX2160ARDB target [2]. > > Tested on LX2160ARDB target with nxp-fspi driver, below are > Read performance number of 1-1-1 and 1-1-8 read protocol. > > root@lxxx:~# cat /proc/mtd > dev:size erasesize name > mtd0: 0400 1000 "spi0.0" > mtd1: 0400 1000 "spi0.1" > root@lxxx:~# time mtd_debug read /dev/mtd0 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m2.792s > user0m0.000s > sys 0m2.790s > root@lxxx:~# time mtd_debug read /dev/mtd1 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m0.441s > user0m0.000s > sys 0m0.440s > root@ls1012ardb:~# > > > Flash device MTD0 configured in 1-1-1 protocol. > Flash device MTD1 configured in 1-1-8 protocol. > > [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70384=* > [2] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=76402 > > Yogesh Gaur (7): > spi: add support for octal mode I/O data transfer > spi: spi-mem: add support for octal mode I/O data transfer These two patches are already merged and is now part of linux-next[1]. Its preferred to send patches based on top of latest linux-next so as to avoid resending patches that have already been picked up by the maintainer. [1] commit 6b03061f882de49b83ccf44beb3a12c920a2da1b Author: Yogesh Narayan Gaur Date: Mon Dec 3 08:39:06 2018 + spi: add support for octal mode I/O data transfer commit b12a084c8729ef423089bb9a5a143eed39cd94e7 Author: Yogesh Narayan Gaur Date: Mon Dec 3 08:39:12 2018 + spi: spi-mem: add support for octal mode I/O data transfer Regards Vignesh > mtd: spi-nor: add opcodes for octal Read/Write commands > mtd: spi-nor: add octal read flag for flash mt35xu512aba > mtd: m25p80: add support of octal mode I/O transfer > spi: nxp-fspi: add octal mode flag bit for octal support > arm64: dts: lx2160a: update fspi node > > Changes for v6: > - Correct S-o-b tag with full author name as 'Yogesh Narayan Gaur'. > - Rebase on top of v4.20-rc5. > Changes for v5: > - Modified string 'octo' as 'octal' in all patches. > Changes for v4: > - Rebase on top of v4.20-rc2. > - Modify octo entries enum value in spi.h. > Changes for v3: > - Add octo mode support in spi_setup(). > - Rename all patches with 'octal' string modified as 'octo'. > Changes for v2: > - Incorporated review comments of Boris and Vignesh. > > Yogesh Gaur (7): > spi: add support for octal mode I/O data transfer > spi: spi-mem: add support for octal mode I/O data transfer > mtd: spi-nor: add opcodes for octal Read/Write commands > mtd: spi-nor: add octal read flag for flash mt35xu512aba > mtd: m25p80: add support of octal mode I/O transfer > spi: nxp-fspi: add octal mode flag bit for octal support > arm64: dts: lx2160a: update fspi node > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 > drivers/mtd/devices/m25p80.c | 9 - > drivers/mtd/spi-nor/spi-nor.c | 19 --- > drivers/spi/spi-mem.c | 9 - > drivers/spi/spi-nxp-fspi.c| 4 ++-- > drivers/spi/spi.c | 12 ++-- > include/linux/mtd/spi-nor.h | 16 > include/linux/spi/spi.h | 4 +++- > 8 files changed, 63 insertions(+), 14 deletions(-) > -- Regards Vignesh
Re: [PATCH 1/2] arm64: dts: ti: k3-am654: Add McSPI DT nodes
On 13-Dec-18 8:29 PM, Tero Kristo wrote:
> On 09/12/2018 12:22, Vignesh R wrote:
>> There are 3 instances of McSPI in MCU domain and 4 instances in Main
>> domain.
>> Add DT nodes for all McSPI instances present on AM654 SoC.
>>
>> Signed-off-by: Vignesh R
>> ---
>> Â arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 52
>>  arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 ++
>> Â 2 files changed, 82 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index 0a0a8fc5df64..6c71e67b8988 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -138,4 +138,56 @@
>> Â clocks = <_clks 39 0>;
>> Â clock-names = "fck";
>> Â };
>> +
>> +Â Â Â main_spi0: spi@210 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>
> WARNING: DT compatible string "ti,am654-mcspi" appears un-documented --
> check ../../Documentation/devicetree/bindings/
> #63: FILE: arch/arm64/boot/dts/ti/k3-am65-main.dtsi:143:
> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>
> Same for the rest of the nodes.
>
> Did you forget documentation part?
>
Documentation patch as been accepted into SPI tree and part of linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=abc61f47a70f7c8331f00eff1ccb6557a9d4c224
Regards
Vignesh
> -Tero
>
>> +Â Â Â reg = <0x0 0x210 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 137 1>;
>> +Â Â Â power-domains = <_pds 137>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â };
>> +
>> +Â Â Â main_spi1: spi@211 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> +Â Â Â reg = <0x0 0x211 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 138 1>;
>> +Â Â Â power-domains = <_pds 138>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â assigned-clocks = <_clks 137 1>;
>> +Â Â Â assigned-clock-rates = <4800>;
>> +Â Â Â };
>> +
>> +Â Â Â main_spi2: spi@212 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> +Â Â Â reg = <0x0 0x212 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 139 1>;
>> +Â Â Â power-domains = <_pds 139>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â };
>> +
>> +Â Â Â main_spi3: spi@213 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> +Â Â Â reg = <0x0 0x213 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 140 1>;
>> +Â Â Â power-domains = <_pds 140>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â };
>> +
>> +Â Â Â main_spi4: spi@214 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> +Â Â Â reg = <0x0 0x214 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 141 1>;
>> +Â Â Â power-domains = <_pds 141>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â };
>> Â };
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> index 1fd027748e1f..1aeae52fb239 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
>> @@ -26,4 +26,34 @@
>> Â clocks = <_clks 114 1>;
>> Â power-domains = <_pds 114>;
>> Â };
>> +
>> +Â Â Â mcu_spi0: spi@4030 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> +Â Â Â reg = <0x0 0x4030 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 142 1>;
>> +Â Â Â power-domains = <_pds 142>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â };
>> +
>> +Â Â Â mcu_spi1: spi@4031 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> +Â Â Â reg = <0x0 0x4031 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 143 1>;
>> +Â Â Â power-domains = <_pds 143>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â };
>> +
>> +Â Â Â mcu_spi2: spi@4032 {
>> +Â Â Â compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> +Â Â Â reg = <0x0 0x4032 0x0 0x400>;
>> +Â Â Â interrupts = ;
>> +Â Â Â clocks = <_clks 144 1>;
>> +Â Â Â power-domains = <_pds 144>;
>> +Â Â Â #address-cells = <1>;
>> +Â Â Â #size-cells = <0>;
>> +Â Â Â };
>> Â };
>>
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] arm64: dts: ti: k3-am654: Populate power-domain property for UART nodes
Populate power-domain property for UART nodes, this is required for
Linux to enable UART clocks via PM calls. Without this UART instances
not initialized by bootloader (like main_uart1) fails to work in Linux.
Also, drop current-speed property from main_uart1 and main_uart2 nodes
as these UARTs are not initialized before Linux boots up and current
speed is unknown.
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++--
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi| 1 +
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 6c71e67b8988..272cf8fc8d30 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -48,6 +48,7 @@
interrupts = ;
clock-frequency = <4800>;
current-speed = <115200>;
+ power-domains = <_pds 146>;
};
main_uart1: serial@281 {
@@ -57,7 +58,7 @@
reg-io-width = <4>;
interrupts = ;
clock-frequency = <4800>;
- current-speed = <115200>;
+ power-domains = <_pds 147>;
};
main_uart2: serial@282 {
@@ -67,7 +68,7 @@
reg-io-width = <4>;
interrupts = ;
clock-frequency = <4800>;
- current-speed = <115200>;
+ power-domains = <_pds 148>;
};
main_pmx0: pinmux@11c000 {
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 1aeae52fb239..593f718e8fb5 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -14,6 +14,7 @@
interrupts = ;
clock-frequency = <9600>;
current-speed = <115200>;
+ power-domains = <_pds 149>;
};
mcu_i2c0: i2c@40b0 {
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index 9e8467ce7ad8..7cbdc0912ab7 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -50,6 +50,7 @@
interrupts = ;
clock-frequency = <4800>;
current-speed = <115200>;
+ power-domains = <_pds 150>;
};
wkup_i2c0: i2c@4212 {
--
2.19.2
[PATCH v2 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- v2 Collect Reviewed-by's Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.19.2
[PATCH v2 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Based on top of [1][2] that add Octal mode support in spi-nor core: [1] https://patchwork.ozlabs.org/patch/1006717/ [2] https://patchwork.ozlabs.org/patch/1006715/ Changes: v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 54 ++- 2 files changed, 43 insertions(+), 12 deletions(-) -- 2.19.2
[PATCH v2 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode.
Signed-off-by: Vignesh R
---
v2:
Declare Octal mode capability based on compatible.
drivers/mtd/spi-nor/cadence-quadspi.c | 54 +--
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..31ed50f78972 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -93,6 +93,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +106,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +917,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1222,19 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+ struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1317,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1384,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = (struct cqspi_driver_platdata *)of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1467,37 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+#define cqspi_base_hwcaps_mask \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
+static const struct cqspi_driver_platdata cdns_qspi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask,
+};
+
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = cqspi_base_hwcaps_mask | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
- .data = (void *)0,
+ .data = (void *)_qspi,
},
{
.compatible = "ti,k2g-qspi",
- .data = (void *)CQSPI_NEEDS_WR_DELAY,
+ .data = (void *)_qspi,
+ },
+ {
+ .compatible = "ti,am654-ospi",
+ .data = (void *)_ospi,
},
{ /* end of table */ }
};
--
2.19.2
Re: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
On 07/12/18 2:12 PM, Faiz Abbas wrote:
> On the am654x-evm, sdhci0 node is connected to an eMMC while sdhci1
> is connected to an SD card slot. Add nodes and pinmuxes for the same.
>
> Signed-off-by: Faiz Abbas
> ---
> .../arm64/boot/dts/ti/k3-am654-base-board.dts | 46 +++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> index bd5a0069191d..5dcd16b787eb 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> @@ -60,6 +60,36 @@
> AM65X_IOPAD(0x0070, PIN_INPUT, 5) /* (R25)
> GPMC0_CSn2.I2C2_SDA */
> >;
> };
> +
> + main_mmc0_pins_default: main_mmc0_pins_default {
make dtbs W=12 will warn you:
Character '_' not recommended in node name
> + pinctrl-single,pins = <
> + AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /* (B25)
> MMC0_CLK */
> + AM65X_IOPAD(0x01ac, PIN_INPUT_PULLUP, 0) /* (B27)
> MMC0_CMD */
> + AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0) /* (A26)
> MMC0_DAT0 */
> + AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0) /* (E25)
> MMC0_DAT1 */
> + AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0) /* (C26)
> MMC0_DAT2 */
> + AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0) /* (A25)
> MMC0_DAT3 */
> + AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0) /* (E24)
> MMC0_DAT4 */
> + AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0) /* (A24)
> MMC0_DAT5 */
> + AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0) /* (B26)
> MMC0_DAT6 */
> + AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0) /* (D25)
> MMC0_DAT7 */
> + AM65X_IOPAD(0x01b4, PIN_INPUT_PULLUP, 0) /* (A23)
> MMC0_SDCD */
> + AM65X_IOPAD(0x01b0, PIN_INPUT, 0) /* (C25) MMC0_DS */
> + >;
> + };
> +
> + main_mmc1_pins_default: main_mmc1_pins_default {
Same here
Regards
Vignesh
> + pinctrl-single,pins = <
> + AM65X_IOPAD(0x02d4, PIN_INPUT_PULLDOWN, 0) /* (C27)
> MMC1_CLK */
> + AM65X_IOPAD(0x02d8, PIN_INPUT_PULLUP, 0) /* (C28)
> MMC1_CMD */
> + AM65X_IOPAD(0x02d0, PIN_INPUT_PULLUP, 0) /* (D28)
> MMC1_DAT0 */
> + AM65X_IOPAD(0x02cc, PIN_INPUT_PULLUP, 0) /* (E27)
> MMC1_DAT1 */
> + AM65X_IOPAD(0x02c8, PIN_INPUT_PULLUP, 0) /* (D26)
> MMC1_DAT2 */
> + AM65X_IOPAD(0x02c4, PIN_INPUT_PULLUP, 0) /* (D27)
> MMC1_DAT3 */
> + AM65X_IOPAD(0x02dc, PIN_INPUT_PULLUP, 0) /* (B24)
> MMC1_SDCD */
> + AM65X_IOPAD(0x02e0, PIN_INPUT, 0) /* (C24) MMC1_SDWP */
> + >;
> + };
> };
>
> _pmx1 {
> @@ -125,3 +155,19 @@
> pinctrl-0 = <_i2c2_pins_default>;
> clock-frequency = <40>;
> };
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mmc0_pins_default>;
> + bus-width = <8>;
> + non-removable;
> + ti,driver-strength-ohm = <50>;
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mmc1_pins_default>;
> + ti,driver-strength-ohm = <50>;
> +};
>
--
Regards
Vignesh
Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
On 10/12/18 2:15 PM, Boris Brezillon wrote:
> On Wed, 3 Oct 2018 22:26:03 +0530
> Vignesh R wrote:
>
>> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
>> It also has an integrated PHY. IP register layout is very
>> similar to existing QSPI IP except for additional bits to support Octal
>> and Octal DDR mode. Therefore, extend current driver to support Octal
>> mode.
>>
>> Signed-off-by: Vignesh R
>> ---
>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
>> b/drivers/mtd/spi-nor/cadence-quadspi.c
>> index e24db817154e..48b00e75a879 100644
>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>> @@ -101,6 +101,7 @@ struct cqspi_st {
>> #define CQSPI_INST_TYPE_SINGLE 0
>> #define CQSPI_INST_TYPE_DUAL1
>> #define CQSPI_INST_TYPE_QUAD2
>> +#define CQSPI_INST_TYPE_OCTAL 3
>>
>> #define CQSPI_DUMMY_CLKS_PER_BYTE 8
>> #define CQSPI_DUMMY_BYTES_MAX 4
>> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
>> int read)
>> case SNOR_PROTO_1_1_4:
>> f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
>> break;
>> +case SNOR_PROTO_1_1_8:
>> +f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
>> +break;
>> default:
>> return -EINVAL;
>> }
>> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
>> struct device_node *np)
>> SNOR_HWCAPS_READ_FAST |
>> SNOR_HWCAPS_READ_1_1_2 |
>> SNOR_HWCAPS_READ_1_1_4 |
>> +SNOR_HWCAPS_READ_1_1_8 |
>
> Is this really supported on qspi versions of this IP? I guess not given
> the description in the commit message and the name of the new
> compatible (ospi instead of qspi).
No, qspi version does not support Octal mode. I guess you are pointing
out its logically wrong for driver with "*-qspi" compatible to declare
SNOR_HWCAPS_READ_1_1_8 capability.
Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible.
>
>> SNOR_HWCAPS_PP,
>> };
>> struct platform_device *pdev = cqspi->pdev;
>> @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = {
>> .compatible = "ti,k2g-qspi",
>> .data = (void *)CQSPI_NEEDS_WR_DELAY,
>> },
>> +{
>> +.compatible = "ti,am654-ospi",
>> +.data = (void *)CQSPI_NEEDS_WR_DELAY,
>> +},
>> { /* end of table */ }
>> };
>>
>
--
Regards
Vignesh
[PATCH 0/2] AM654: Add McSPI DT entry
Couple of patches to add support for McSPIs in AM654 SoC. Vignesh R (2): arm64: dts: ti: k3-am654: Add McSPI DT nodes arm64: dts: ti: k3-am654: Enable main domain McSPI0 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 52 +++ arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 +++ .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 ++ 3 files changed, 109 insertions(+) -- 2.19.2
[PATCH 1/2] arm64: dts: ti: k3-am654: Add McSPI DT nodes
There are 3 instances of McSPI in MCU domain and 4 instances in Main domain.
Add DT nodes for all McSPI instances present on AM654 SoC.
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 52
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 ++
2 files changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 0a0a8fc5df64..6c71e67b8988 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -138,4 +138,56 @@
clocks = <_clks 39 0>;
clock-names = "fck";
};
+
+ main_spi0: spi@210 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x210 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 137 1>;
+ power-domains = <_pds 137>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi1: spi@211 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x211 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 138 1>;
+ power-domains = <_pds 138>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ assigned-clocks = <_clks 137 1>;
+ assigned-clock-rates = <4800>;
+ };
+
+ main_spi2: spi@212 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x212 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 139 1>;
+ power-domains = <_pds 139>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi3: spi@213 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x213 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 140 1>;
+ power-domains = <_pds 140>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi4: spi@214 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x214 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 141 1>;
+ power-domains = <_pds 141>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 1fd027748e1f..1aeae52fb239 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -26,4 +26,34 @@
clocks = <_clks 114 1>;
power-domains = <_pds 114>;
};
+
+ mcu_spi0: spi@4030 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4030 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 142 1>;
+ power-domains = <_pds 142>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mcu_spi1: spi@4031 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4031 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 143 1>;
+ power-domains = <_pds 143>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mcu_spi2: spi@4032 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4032 0x0 0x400>;
+ interrupts = ;
+ clocks = <_clks 144 1>;
+ power-domains = <_pds 144>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
--
2.19.2
[PATCH 2/2] arm64: dts: ti: k3-am654: Enable main domain McSPI0
Enable McSPI0 of main domain and add DT node for the SPI NOR flash
connected to CS0.
Signed-off-by: Vignesh R
---
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 49ec2c3f5ef1..e41fc3a5987b 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -60,6 +60,15 @@
AM65X_IOPAD(0x0070, PIN_INPUT, 5) /* (R25)
GPMC0_CSn2.I2C2_SDA */
>;
};
+
+ main_spi0_pins_default: main-spi0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01c4, PIN_INPUT, 0) /* (AH13) SPI0_CLK */
+ AM65X_IOPAD(0x01c8, PIN_INPUT, 0) /* (AE13) SPI0_D0 */
+ AM65X_IOPAD(0x01cc, PIN_INPUT, 0) /* (AD13) SPI0_D1 */
+ AM65X_IOPAD(0x01bc, PIN_OUTPUT, 0) /* (AG13) SPI0_CS0 */
+ >;
+ };
};
_pmx1 {
@@ -136,3 +145,21 @@
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
};
+
+_spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_spi0_pins_default>;
+ #address-cells = <1>;
+ #size-cells= <0>;
+ ti,pindir-d0-out-d1-in = <1>;
+
+ flash@0{
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ spi-max-frequency = <4800>;
+ #address-cells = <1>;
+ #size-cells= <1>;
+ };
+};
--
2.19.2
Re: [PATCH 0/3] spi-nor: Add Octal SPI support
Hi Boris, On 03/10/18 10:26 PM, Vignesh R wrote: > This series adds support for octal mode of mt35x flash. Also, adds > support for OSPI version of Cadence QSPI controller. > > Based on top of patches adding basic support for mt35xu512aba here: > https://patchwork.ozlabs.org/cover/971437/ > > Vignesh R (3): > mtd: spi-nor: Add Octal mode support for mt35xu512aba > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller Could you consider above two patches for v4.21 once [1][2] are merged? [1] https://patchwork.ozlabs.org/patch/1006717/ [2] https://patchwork.ozlabs.org/patch/1006715/ Let me know if this needs to be re-posted. > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > drivers/mtd/spi-nor/cadence-quadspi.c | 9 + > drivers/mtd/spi-nor/spi-nor.c | 11 ++- > include/linux/mtd/spi-nor.h | 2 ++ > 4 files changed, 22 insertions(+), 1 deletion(-) > -- Regards Vignesh
Re: [PATCH 1/2] arm64: dts: ti: k3-am654: Add Support for MMC/SD
On 07/12/18 2:12 PM, Faiz Abbas wrote:
> There are two MMC host controller instances present on the TI's
> Am654 SOCs. Add device tree nodes for the same.
>
> Signed-off-by: Faiz Abbas
> ---
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index 916434839603..d07212f16a81 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -129,4 +129,32 @@
> clocks = <_clks 113 1>;
> power-domains = <_pds 113>;
> };
> +
> + sdhci0: sdhci@4f8 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
> + power-domains = <_pds 47>;
> + clocks = <_clks 47 0>, <_clks 47 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + sdhci-caps-mask = <0x8007 0x0>;
> + mmc-ddr-1_8v;
> + ti,otap-del-sel = <0x2>;
> + ti,trm-icp = <0x8>;
> + status = "disabled";
> + };
Please drop "status=disabled" from dtsi. Can be disabled as required in
the board dts.
> +
> + sdhci1: sdhci@4fa {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4fa 0x0 0x260>, <0x0 0x4fb 0x0 0x134>;
> + power-domains = <_pds 48>;
> + clocks = <_clks 48 0>, <_clks 48 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + sdhci-caps-mask = <0x8007 0x0>;
> + mmc-ddr-1_8v;
> + ti,otap-del-sel = <0x2>;
> + ti,trm-icp = <0x8>;
> + status = "disabled";
> + };
> };
>
--
Regards
Vignesh
Re: [PATCH 1/2] arm64: dts: ti: k3-am654: Add Support for MMC/SD
On 07/12/18 2:12 PM, Faiz Abbas wrote:
> There are two MMC host controller instances present on the TI's
> Am654 SOCs. Add device tree nodes for the same.
>
> Signed-off-by: Faiz Abbas
> ---
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index 916434839603..d07212f16a81 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -129,4 +129,32 @@
> clocks = <_clks 113 1>;
> power-domains = <_pds 113>;
> };
> +
> + sdhci0: sdhci@4f8 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
> + power-domains = <_pds 47>;
> + clocks = <_clks 47 0>, <_clks 47 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + sdhci-caps-mask = <0x8007 0x0>;
> + mmc-ddr-1_8v;
> + ti,otap-del-sel = <0x2>;
> + ti,trm-icp = <0x8>;
> + status = "disabled";
> + };
Please drop "status=disabled" from dtsi. Can be disabled as required in
the board dts.
> +
> + sdhci1: sdhci@4fa {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4fa 0x0 0x260>, <0x0 0x4fb 0x0 0x134>;
> + power-domains = <_pds 48>;
> + clocks = <_clks 48 0>, <_clks 48 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + sdhci-caps-mask = <0x8007 0x0>;
> + mmc-ddr-1_8v;
> + ti,otap-del-sel = <0x2>;
> + ti,trm-icp = <0x8>;
> + status = "disabled";
> + };
> };
>
--
Regards
Vignesh
[PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Enable ECAP PWM
Enable ECAP PWM which is used for LCD backlight.
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index bd5a0069191d..49ec2c3f5ef1 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -76,6 +76,12 @@
AM65X_IOPAD(0x000c, PIN_INPUT, 0) /* (E21) I2C1_SDA */
>;
};
+
+ ecap0_pins_default: ecap0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0010, PIN_INPUT, 0) /* (D21)
ECAP0_IN_APWM_OUT */
+ >;
+ };
};
_uart0 {
@@ -125,3 +131,8 @@
pinctrl-0 = <_i2c2_pins_default>;
clock-frequency = <40>;
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+};
--
2.19.2
[PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Enable ECAP PWM
Enable ECAP PWM which is used for LCD backlight.
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index bd5a0069191d..49ec2c3f5ef1 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -76,6 +76,12 @@
AM65X_IOPAD(0x000c, PIN_INPUT, 0) /* (E21) I2C1_SDA */
>;
};
+
+ ecap0_pins_default: ecap0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0010, PIN_INPUT, 0) /* (D21)
ECAP0_IN_APWM_OUT */
+ >;
+ };
};
_uart0 {
@@ -125,3 +131,8 @@
pinctrl-0 = <_i2c2_pins_default>;
clock-frequency = <40>;
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+};
--
2.19.2
[PATCH 0/2] AM654: Add ECAP PWM support
Couple of patches to add ECAP PWM support for AM654 SoC. Based on top of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux.git 4.20-rc1-am65x-queue Vignesh R (2): arm64: dts: ti: k3-am65-main: Add ECAP PWM node arm64: dts: ti: k3-am654-base-board: Enable ECAP PWM arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 9 + arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 11 +++ 2 files changed, 20 insertions(+) -- 2.19.2
[PATCH 0/2] AM654: Add ECAP PWM support
Couple of patches to add ECAP PWM support for AM654 SoC. Based on top of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux.git 4.20-rc1-am65x-queue Vignesh R (2): arm64: dts: ti: k3-am65-main: Add ECAP PWM node arm64: dts: ti: k3-am654-base-board: Enable ECAP PWM arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 9 + arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 11 +++ 2 files changed, 20 insertions(+) -- 2.19.2
[PATCH 1/2] arm64: dts: ti: k3-am65-main: Add ECAP PWM node
Add DT entry for ECAP0 PWM node present in main domain
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 916434839603..0a0a8fc5df64 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -129,4 +129,13 @@
clocks = <_clks 113 1>;
power-domains = <_pds 113>;
};
+
+ ecap0: pwm@310 {
+ compatible = "ti,am654-ecap", "ti,am3352-ecap";
+ #pwm-cells = <3>;
+ reg = <0x0 0x0310 0x0 0x60>;
+ power-domains = <_pds 39>;
+ clocks = <_clks 39 0>;
+ clock-names = "fck";
+ };
};
--
2.19.2
[PATCH 1/2] arm64: dts: ti: k3-am65-main: Add ECAP PWM node
Add DT entry for ECAP0 PWM node present in main domain
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 916434839603..0a0a8fc5df64 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -129,4 +129,13 @@
clocks = <_clks 113 1>;
power-domains = <_pds 113>;
};
+
+ ecap0: pwm@310 {
+ compatible = "ti,am654-ecap", "ti,am3352-ecap";
+ #pwm-cells = <3>;
+ reg = <0x0 0x0310 0x0 0x60>;
+ power-domains = <_pds 39>;
+ clocks = <_clks 39 0>;
+ clock-names = "fck";
+ };
};
--
2.19.2
Re: [PATCH v5 0/7] spi: add support for octal mode
Hi Boris, On 03/12/18 2:49 PM, Boris Brezillon wrote: > Hi Mark, > > On Mon, 3 Dec 2018 08:39:00 + > Yogesh Narayan Gaur wrote: > >> >> Yogesh Gaur (7): >> spi: add support for octal mode I/O data transfer >> spi: spi-mem: add support for octal mode I/O data transfer > > Can you take those 2 patches in your tree for 4.21/5.0? > >> mtd: spi-nor: add opcodes for octal Read/Write commands >> mtd: spi-nor: add octal read flag for flash mt35xu512aba Could you consider merging these two patches alone for v4.21? These can be applied independent of other patches in the series and would allow supporting OSPI flash at SPI NOR level with Cadence QSPI driver. >> mtd: m25p80: add support of octal mode I/O transfer >> spi: nxp-fspi: add octal mode flag bit for octal support > > I'll queue these ones after 4.21-rc1/5.0-rc1 is out (which means > they'll appear in 4.22/5.1). > >> arm64: dts: lx2160a: update fspi node -- Regards Vignesh
Re: [PATCH v5 0/7] spi: add support for octal mode
Hi Boris, On 03/12/18 2:49 PM, Boris Brezillon wrote: > Hi Mark, > > On Mon, 3 Dec 2018 08:39:00 + > Yogesh Narayan Gaur wrote: > >> >> Yogesh Gaur (7): >> spi: add support for octal mode I/O data transfer >> spi: spi-mem: add support for octal mode I/O data transfer > > Can you take those 2 patches in your tree for 4.21/5.0? > >> mtd: spi-nor: add opcodes for octal Read/Write commands >> mtd: spi-nor: add octal read flag for flash mt35xu512aba Could you consider merging these two patches alone for v4.21? These can be applied independent of other patches in the series and would allow supporting OSPI flash at SPI NOR level with Cadence QSPI driver. >> mtd: m25p80: add support of octal mode I/O transfer >> spi: nxp-fspi: add octal mode flag bit for octal support > > I'll queue these ones after 4.21-rc1/5.0-rc1 is out (which means > they'll appear in 4.22/5.1). > >> arm64: dts: lx2160a: update fspi node -- Regards Vignesh
Re: [PATCH] dt-bindings: ti-tsc-adc: Add new compatible for AM654 SoCs
Hi, On 19/11/18 3:15 PM, Vignesh R wrote: > AM654 SoCs has ADC IP which is similar to AM335x. Add new compatible to > handle AM654 SoCs. Also, it seems that existing compatible strings used > in the kernel DTs were never documented. So, document them now. > > Signed-off-by: Vignesh R > --- Gentle ping on this patch.. > .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > index b1163bf97146..aad5e34965eb 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > @@ -2,7 +2,12 @@ > ~~ > > Required properties: > +- mfd > + compatible: Should be > + "ti,am3359-tscadc" for AM335x/AM437x SoCs > + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs > - child "tsc" > + compatible: Should be "ti,am3359-tsc". > ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen > support on the platform. > ti,x-plate-resistance: X plate resistance > @@ -25,6 +30,9 @@ Required properties: > AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > XP = 0, XN = 1, YP = 2, YN = 3. > - child "adc" > + compatible: Should be > + "ti,am3359-adc" for AM335x/AM437x SoCs > + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs > ti,adc-channels: List of analog inputs available for ADC. >AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > > -- Regards Vignesh
Re: [PATCH] dt-bindings: ti-tsc-adc: Add new compatible for AM654 SoCs
Hi, On 19/11/18 3:15 PM, Vignesh R wrote: > AM654 SoCs has ADC IP which is similar to AM335x. Add new compatible to > handle AM654 SoCs. Also, it seems that existing compatible strings used > in the kernel DTs were never documented. So, document them now. > > Signed-off-by: Vignesh R > --- Gentle ping on this patch.. > .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > index b1163bf97146..aad5e34965eb 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt > @@ -2,7 +2,12 @@ > ~~ > > Required properties: > +- mfd > + compatible: Should be > + "ti,am3359-tscadc" for AM335x/AM437x SoCs > + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs > - child "tsc" > + compatible: Should be "ti,am3359-tsc". > ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen > support on the platform. > ti,x-plate-resistance: X plate resistance > @@ -25,6 +30,9 @@ Required properties: > AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > XP = 0, XN = 1, YP = 2, YN = 3. > - child "adc" > + compatible: Should be > + "ti,am3359-adc" for AM335x/AM437x SoCs > + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs > ti,adc-channels: List of analog inputs available for ADC. >AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. > > -- Regards Vignesh
[PATCH v2 1/2] mfd: ti_am335x_tscadc: Use PLATFORM_DEVID_AUTO while registering mfd cells
Use PLATFORM_DEVID_AUTO to number mfd cells while registering, so that different instances are uniquely identified. This is required in order to support registering of multiple instances of same ti_am335x_tscadc IP. Signed-off-by: Vignesh R --- v2: use PLATFORM_DEVID_AUTO as suggested by Lee Jones drivers/mfd/ti_am335x_tscadc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c index c2d47d78705b..fd111296b959 100644 --- a/drivers/mfd/ti_am335x_tscadc.c +++ b/drivers/mfd/ti_am335x_tscadc.c @@ -264,8 +264,9 @@ static int ti_tscadc_probe(struct platform_device *pdev) cell->pdata_size = sizeof(tscadc); } - err = mfd_add_devices(>dev, pdev->id, tscadc->cells, - tscadc->used_cells, NULL, 0, NULL); + err = mfd_add_devices(>dev, PLATFORM_DEVID_AUTO, + tscadc->cells, tscadc->used_cells, NULL, + 0, NULL); if (err < 0) goto err_disable_clk; -- 2.19.2
[PATCH v2 1/2] mfd: ti_am335x_tscadc: Use PLATFORM_DEVID_AUTO while registering mfd cells
Use PLATFORM_DEVID_AUTO to number mfd cells while registering, so that different instances are uniquely identified. This is required in order to support registering of multiple instances of same ti_am335x_tscadc IP. Signed-off-by: Vignesh R --- v2: use PLATFORM_DEVID_AUTO as suggested by Lee Jones drivers/mfd/ti_am335x_tscadc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c index c2d47d78705b..fd111296b959 100644 --- a/drivers/mfd/ti_am335x_tscadc.c +++ b/drivers/mfd/ti_am335x_tscadc.c @@ -264,8 +264,9 @@ static int ti_tscadc_probe(struct platform_device *pdev) cell->pdata_size = sizeof(tscadc); } - err = mfd_add_devices(>dev, pdev->id, tscadc->cells, - tscadc->used_cells, NULL, 0, NULL); + err = mfd_add_devices(>dev, PLATFORM_DEVID_AUTO, + tscadc->cells, tscadc->used_cells, NULL, + 0, NULL); if (err < 0) goto err_disable_clk; -- 2.19.2
[PATCH v2 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to VREFP and VREFN
respectively in STEP_CONFIGx register.
Without these changes, there may be variation of as much as ~2% in the
ADC's digital output which is bad for precise measurement.
Signed-off-by: Vignesh R
Acked-by: Jonathan Cameron
Acked-by: Lee Jones
---
v2: No change
drivers/iio/adc/ti_am335x_adc.c | 5 -
include/linux/mfd/ti_am335x_tscadc.h | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index cafb1dcadc48..9d984f2a8ba7 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
stepconfig |= STEPCONFIG_MODE_SWCNT;
tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
- stepconfig | STEPCONFIG_INP(chan));
+ stepconfig | STEPCONFIG_INP(chan) |
+ STEPCONFIG_INM_ADCREFM |
+ STEPCONFIG_RFP_VREFP |
+ STEPCONFIG_RFM_VREFN);
if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
dev_warn(dev, "chan %d open delay truncating to
0x3\n",
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index b9a53e013bff..483168403ae5 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -78,6 +78,8 @@
#define STEPCONFIG_YNN BIT(8)
#define STEPCONFIG_XNP BIT(9)
#define STEPCONFIG_YPN BIT(10)
+#define STEPCONFIG_RFP(val)((val) << 12)
+#define STEPCONFIG_RFP_VREFP (0x3 << 12)
#define STEPCONFIG_INM_MASK(0xF << 15)
#define STEPCONFIG_INM(val)((val) << 15)
#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
@@ -86,6 +88,8 @@
#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
#define STEPCONFIG_FIFO1 BIT(26)
+#define STEPCONFIG_RFM(val)((val) << 23)
+#define STEPCONFIG_RFM_VREFN (0x3 << 23)
/* Delay register */
#define STEPDELAY_OPEN_MASK(0x3 << 0)
--
2.19.2
[PATCH v2 0/2] tscadc: Couple of fixes
Couple of fixes for tscadc drivers that I found while adding support for new SoC. Vignesh R (2): mfd: ti_am335x_tscadc: Use PLATFORM_DEVID_AUTO while registering mfd cells iio: adc: ti_am335x_tscadc: Improve accuracy of measurement drivers/iio/adc/ti_am335x_adc.c | 5 - drivers/mfd/ti_am335x_tscadc.c | 5 +++-- include/linux/mfd/ti_am335x_tscadc.h | 4 3 files changed, 11 insertions(+), 3 deletions(-) -- 2.19.2
[PATCH v2 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to VREFP and VREFN
respectively in STEP_CONFIGx register.
Without these changes, there may be variation of as much as ~2% in the
ADC's digital output which is bad for precise measurement.
Signed-off-by: Vignesh R
Acked-by: Jonathan Cameron
Acked-by: Lee Jones
---
v2: No change
drivers/iio/adc/ti_am335x_adc.c | 5 -
include/linux/mfd/ti_am335x_tscadc.h | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index cafb1dcadc48..9d984f2a8ba7 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
stepconfig |= STEPCONFIG_MODE_SWCNT;
tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
- stepconfig | STEPCONFIG_INP(chan));
+ stepconfig | STEPCONFIG_INP(chan) |
+ STEPCONFIG_INM_ADCREFM |
+ STEPCONFIG_RFP_VREFP |
+ STEPCONFIG_RFM_VREFN);
if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
dev_warn(dev, "chan %d open delay truncating to
0x3\n",
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index b9a53e013bff..483168403ae5 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -78,6 +78,8 @@
#define STEPCONFIG_YNN BIT(8)
#define STEPCONFIG_XNP BIT(9)
#define STEPCONFIG_YPN BIT(10)
+#define STEPCONFIG_RFP(val)((val) << 12)
+#define STEPCONFIG_RFP_VREFP (0x3 << 12)
#define STEPCONFIG_INM_MASK(0xF << 15)
#define STEPCONFIG_INM(val)((val) << 15)
#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
@@ -86,6 +88,8 @@
#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
#define STEPCONFIG_FIFO1 BIT(26)
+#define STEPCONFIG_RFM(val)((val) << 23)
+#define STEPCONFIG_RFM_VREFN (0x3 << 23)
/* Delay register */
#define STEPDELAY_OPEN_MASK(0x3 << 0)
--
2.19.2
[PATCH v2 0/2] tscadc: Couple of fixes
Couple of fixes for tscadc drivers that I found while adding support for new SoC. Vignesh R (2): mfd: ti_am335x_tscadc: Use PLATFORM_DEVID_AUTO while registering mfd cells iio: adc: ti_am335x_tscadc: Improve accuracy of measurement drivers/iio/adc/ti_am335x_adc.c | 5 - drivers/mfd/ti_am335x_tscadc.c | 5 +++-- include/linux/mfd/ti_am335x_tscadc.h | 4 3 files changed, 11 insertions(+), 3 deletions(-) -- 2.19.2
Re: [PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
On 28/11/18 4:33 PM, Lee Jones wrote:
> On Wed, 28 Nov 2018, Vignesh R wrote:
>
>> Hi,
>>
>> On 28/11/18 2:37 PM, Lee Jones wrote:
>>> On Mon, 19 Nov 2018, Vignesh R wrote:
>>>
>>>> Provide unique names for child mfd cells, this is required in order to
>>>> support registering of multiple instances of same ti_am335x_tscadc IP.
>>>
>>> I don't think it is. What is the error you are receiving?
>>
>> W/o this patch I get:
>>
>> [2.296839] sysfs: cannot create duplicate filename
>> '/bus/platform/devices/TI-am335x-adc'
>> [2.305085] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted
>> 4.20.0-rc3-next-20181123-00018-g
>> 7791ce8f123f-dirty #182
>> [2.315254] Hardware name: Texas Instruments AM654 Base Board (DT)
>> [2.321447] Workqueue: events deferred_probe_work_func
>> [2.326585] Call trace:
>> [2.329036] dump_backtrace+0x0/0x1c0
>> [2.332699] show_stack+0x14/0x20
>> [2.336017] dump_stack+0x9c/0xbc
>> [2.339333] sysfs_warn_dup+0x60/0x78
>> [2.342995] sysfs_do_create_link_sd.isra.0+0xdc/0xe8
>> [2.348042] sysfs_create_link+0x20/0x40
>> [2.351963] bus_add_device+0x68/0x130
>> [2.355711] device_add+0x398/0x618
>> [2.359199] platform_device_add+0x120/0x290
>> [2.363469] mfd_add_device+0x23c/0x2e8
>> [2.367302] mfd_add_devices+0xb4/0x158
>> [2.371136] ti_tscadc_probe+0x35c/0x4c8
>> [2.375056] platform_drv_probe+0x50/0xa0
>> [2.379062] really_probe+0x204/0x2a8
>> [2.382722] driver_probe_device+0x58/0x100
>> [2.386903] __device_attach_driver+0x98/0xf0
>> [2.391258] bus_for_each_drv+0x64/0xc8
>> [2.395091] __device_attach+0xd8/0x138
>> [2.398923] device_initial_probe+0x10/0x18
>> [2.403103] bus_probe_device+0x90/0x98
>> [2.406938] deferred_probe_work_func+0x74/0xb0
>> [2.411470] process_one_work+0x1e0/0x330
>> [2.415478] worker_thread+0x238/0x460
>> [2.419225] kthread+0x128/0x130
>> [2.422452] ret_from_fork+0x10/0x1c
>> [2.426195] ti_am3359-tscadc: probe of 4021.tscadc failed with error
>> -1
>
> That's because of the way the cells are being registered:
>
> err = mfd_add_devices(>dev, pdev->id, tscadc->cells,
> tscadc->used_cells, NULL, 0, NULL);
>
> The cells are not numbered (tscadc->cells->id is always 0) and you are
> forcing the use of the platform ID from the parent platform device
> (with pdev->id here). Instead you should s/pdev->id/PLATFORM_DEVID_AUTO/
> or number the cells manually. I suggest the former.
>
Using PLATFORM_DEVID_AUTO works fine. I will post v2 with this change.
Thanks for the suggestion!
Regards
Vignesh
>>>> Signed-off-by: Vignesh R
>>>> ---
>>>> drivers/mfd/ti_am335x_tscadc.c | 6 --
>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/mfd/ti_am335x_tscadc.c
>>>> b/drivers/mfd/ti_am335x_tscadc.c
>>>> index c2d47d78705b..ee08af34f81d 100644
>>>> --- a/drivers/mfd/ti_am335x_tscadc.c
>>>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>>>> @@ -248,7 +248,8 @@ static int ti_tscadc_probe(struct platform_device
>>>> *pdev)
>>>>if (tsc_wires > 0) {
>>>>tscadc->tsc_cell = tscadc->used_cells;
>>>>cell = >cells[tscadc->used_cells++];
>>>> - cell->name = "TI-am335x-tsc";
>>>> + cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>>>> + dev_name(>dev), "tsc");
>>>>cell->of_compatible = "ti,am3359-tsc";
>>>>cell->platform_data =
>>>>cell->pdata_size = sizeof(tscadc);
>>>> @@ -258,7 +259,8 @@ static int ti_tscadc_probe(struct platform_device
>>>> *pdev)
>>>>if (adc_channels > 0) {
>>>>tscadc->adc_cell = tscadc->used_cells;
>>>>cell = >cells[tscadc->used_cells++];
>>>> - cell->name = "TI-am335x-adc";
>>>> + cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>>>> + dev_name(>dev), "adc");
>>>>cell->of_compatible = "ti,am3359-adc";
>>>>cell->platform_data =
>>>>cell->pdata_size = sizeof(tscadc);
>>>
>>
>
--
Regards
Vignesh
Re: [PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
On 28/11/18 4:33 PM, Lee Jones wrote:
> On Wed, 28 Nov 2018, Vignesh R wrote:
>
>> Hi,
>>
>> On 28/11/18 2:37 PM, Lee Jones wrote:
>>> On Mon, 19 Nov 2018, Vignesh R wrote:
>>>
>>>> Provide unique names for child mfd cells, this is required in order to
>>>> support registering of multiple instances of same ti_am335x_tscadc IP.
>>>
>>> I don't think it is. What is the error you are receiving?
>>
>> W/o this patch I get:
>>
>> [2.296839] sysfs: cannot create duplicate filename
>> '/bus/platform/devices/TI-am335x-adc'
>> [2.305085] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted
>> 4.20.0-rc3-next-20181123-00018-g
>> 7791ce8f123f-dirty #182
>> [2.315254] Hardware name: Texas Instruments AM654 Base Board (DT)
>> [2.321447] Workqueue: events deferred_probe_work_func
>> [2.326585] Call trace:
>> [2.329036] dump_backtrace+0x0/0x1c0
>> [2.332699] show_stack+0x14/0x20
>> [2.336017] dump_stack+0x9c/0xbc
>> [2.339333] sysfs_warn_dup+0x60/0x78
>> [2.342995] sysfs_do_create_link_sd.isra.0+0xdc/0xe8
>> [2.348042] sysfs_create_link+0x20/0x40
>> [2.351963] bus_add_device+0x68/0x130
>> [2.355711] device_add+0x398/0x618
>> [2.359199] platform_device_add+0x120/0x290
>> [2.363469] mfd_add_device+0x23c/0x2e8
>> [2.367302] mfd_add_devices+0xb4/0x158
>> [2.371136] ti_tscadc_probe+0x35c/0x4c8
>> [2.375056] platform_drv_probe+0x50/0xa0
>> [2.379062] really_probe+0x204/0x2a8
>> [2.382722] driver_probe_device+0x58/0x100
>> [2.386903] __device_attach_driver+0x98/0xf0
>> [2.391258] bus_for_each_drv+0x64/0xc8
>> [2.395091] __device_attach+0xd8/0x138
>> [2.398923] device_initial_probe+0x10/0x18
>> [2.403103] bus_probe_device+0x90/0x98
>> [2.406938] deferred_probe_work_func+0x74/0xb0
>> [2.411470] process_one_work+0x1e0/0x330
>> [2.415478] worker_thread+0x238/0x460
>> [2.419225] kthread+0x128/0x130
>> [2.422452] ret_from_fork+0x10/0x1c
>> [2.426195] ti_am3359-tscadc: probe of 4021.tscadc failed with error
>> -1
>
> That's because of the way the cells are being registered:
>
> err = mfd_add_devices(>dev, pdev->id, tscadc->cells,
> tscadc->used_cells, NULL, 0, NULL);
>
> The cells are not numbered (tscadc->cells->id is always 0) and you are
> forcing the use of the platform ID from the parent platform device
> (with pdev->id here). Instead you should s/pdev->id/PLATFORM_DEVID_AUTO/
> or number the cells manually. I suggest the former.
>
Using PLATFORM_DEVID_AUTO works fine. I will post v2 with this change.
Thanks for the suggestion!
Regards
Vignesh
>>>> Signed-off-by: Vignesh R
>>>> ---
>>>> drivers/mfd/ti_am335x_tscadc.c | 6 --
>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/mfd/ti_am335x_tscadc.c
>>>> b/drivers/mfd/ti_am335x_tscadc.c
>>>> index c2d47d78705b..ee08af34f81d 100644
>>>> --- a/drivers/mfd/ti_am335x_tscadc.c
>>>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>>>> @@ -248,7 +248,8 @@ static int ti_tscadc_probe(struct platform_device
>>>> *pdev)
>>>>if (tsc_wires > 0) {
>>>>tscadc->tsc_cell = tscadc->used_cells;
>>>>cell = >cells[tscadc->used_cells++];
>>>> - cell->name = "TI-am335x-tsc";
>>>> + cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>>>> + dev_name(>dev), "tsc");
>>>>cell->of_compatible = "ti,am3359-tsc";
>>>>cell->platform_data =
>>>>cell->pdata_size = sizeof(tscadc);
>>>> @@ -258,7 +259,8 @@ static int ti_tscadc_probe(struct platform_device
>>>> *pdev)
>>>>if (adc_channels > 0) {
>>>>tscadc->adc_cell = tscadc->used_cells;
>>>>cell = >cells[tscadc->used_cells++];
>>>> - cell->name = "TI-am335x-adc";
>>>> + cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>>>> + dev_name(>dev), "adc");
>>>>cell->of_compatible = "ti,am3359-adc";
>>>>cell->platform_data =
>>>>cell->pdata_size = sizeof(tscadc);
>>>
>>
>
--
Regards
Vignesh
Re: [PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
Hi,
On 28/11/18 2:37 PM, Lee Jones wrote:
> On Mon, 19 Nov 2018, Vignesh R wrote:
>
>> Provide unique names for child mfd cells, this is required in order to
>> support registering of multiple instances of same ti_am335x_tscadc IP.
>
> I don't think it is. What is the error you are receiving?
>
W/o this patch I get:
[2.296839] sysfs: cannot create duplicate filename
'/bus/platform/devices/TI-am335x-adc'
[2.305085] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted
4.20.0-rc3-next-20181123-00018-g
7791ce8f123f-dirty #182
[2.315254] Hardware name: Texas Instruments AM654 Base Board (DT)
[2.321447] Workqueue: events deferred_probe_work_func
[2.326585] Call trace:
[2.329036] dump_backtrace+0x0/0x1c0
[2.332699] show_stack+0x14/0x20
[2.336017] dump_stack+0x9c/0xbc
[2.339333] sysfs_warn_dup+0x60/0x78
[2.342995] sysfs_do_create_link_sd.isra.0+0xdc/0xe8
[2.348042] sysfs_create_link+0x20/0x40
[2.351963] bus_add_device+0x68/0x130
[2.355711] device_add+0x398/0x618
[2.359199] platform_device_add+0x120/0x290
[2.363469] mfd_add_device+0x23c/0x2e8
[2.367302] mfd_add_devices+0xb4/0x158
[2.371136] ti_tscadc_probe+0x35c/0x4c8
[2.375056] platform_drv_probe+0x50/0xa0
[2.379062] really_probe+0x204/0x2a8
[2.382722] driver_probe_device+0x58/0x100
[2.386903] __device_attach_driver+0x98/0xf0
[2.391258] bus_for_each_drv+0x64/0xc8
[2.395091] __device_attach+0xd8/0x138
[2.398923] device_initial_probe+0x10/0x18
[2.403103] bus_probe_device+0x90/0x98
[2.406938] deferred_probe_work_func+0x74/0xb0
[2.411470] process_one_work+0x1e0/0x330
[2.415478] worker_thread+0x238/0x460
[2.419225] kthread+0x128/0x130
[2.422452] ret_from_fork+0x10/0x1c
[2.426195] ti_am3359-tscadc: probe of 4021.tscadc failed with error -1
>> Signed-off-by: Vignesh R
>> ---
>> drivers/mfd/ti_am335x_tscadc.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
>> index c2d47d78705b..ee08af34f81d 100644
>> --- a/drivers/mfd/ti_am335x_tscadc.c
>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>> @@ -248,7 +248,8 @@ static int ti_tscadc_probe(struct platform_device
>> *pdev)
>> if (tsc_wires > 0) {
>> tscadc->tsc_cell = tscadc->used_cells;
>> cell = >cells[tscadc->used_cells++];
>> -cell->name = "TI-am335x-tsc";
>> +cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>> +dev_name(>dev), "tsc");
>> cell->of_compatible = "ti,am3359-tsc";
>> cell->platform_data =
>> cell->pdata_size = sizeof(tscadc);
>> @@ -258,7 +259,8 @@ static int ti_tscadc_probe(struct platform_device
>> *pdev)
>> if (adc_channels > 0) {
>> tscadc->adc_cell = tscadc->used_cells;
>> cell = >cells[tscadc->used_cells++];
>> -cell->name = "TI-am335x-adc";
>> +cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>> +dev_name(>dev), "adc");
>> cell->of_compatible = "ti,am3359-adc";
>> cell->platform_data =
>> cell->pdata_size = sizeof(tscadc);
>
--
Regards
Vignesh
Re: [PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
Hi,
On 28/11/18 2:37 PM, Lee Jones wrote:
> On Mon, 19 Nov 2018, Vignesh R wrote:
>
>> Provide unique names for child mfd cells, this is required in order to
>> support registering of multiple instances of same ti_am335x_tscadc IP.
>
> I don't think it is. What is the error you are receiving?
>
W/o this patch I get:
[2.296839] sysfs: cannot create duplicate filename
'/bus/platform/devices/TI-am335x-adc'
[2.305085] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted
4.20.0-rc3-next-20181123-00018-g
7791ce8f123f-dirty #182
[2.315254] Hardware name: Texas Instruments AM654 Base Board (DT)
[2.321447] Workqueue: events deferred_probe_work_func
[2.326585] Call trace:
[2.329036] dump_backtrace+0x0/0x1c0
[2.332699] show_stack+0x14/0x20
[2.336017] dump_stack+0x9c/0xbc
[2.339333] sysfs_warn_dup+0x60/0x78
[2.342995] sysfs_do_create_link_sd.isra.0+0xdc/0xe8
[2.348042] sysfs_create_link+0x20/0x40
[2.351963] bus_add_device+0x68/0x130
[2.355711] device_add+0x398/0x618
[2.359199] platform_device_add+0x120/0x290
[2.363469] mfd_add_device+0x23c/0x2e8
[2.367302] mfd_add_devices+0xb4/0x158
[2.371136] ti_tscadc_probe+0x35c/0x4c8
[2.375056] platform_drv_probe+0x50/0xa0
[2.379062] really_probe+0x204/0x2a8
[2.382722] driver_probe_device+0x58/0x100
[2.386903] __device_attach_driver+0x98/0xf0
[2.391258] bus_for_each_drv+0x64/0xc8
[2.395091] __device_attach+0xd8/0x138
[2.398923] device_initial_probe+0x10/0x18
[2.403103] bus_probe_device+0x90/0x98
[2.406938] deferred_probe_work_func+0x74/0xb0
[2.411470] process_one_work+0x1e0/0x330
[2.415478] worker_thread+0x238/0x460
[2.419225] kthread+0x128/0x130
[2.422452] ret_from_fork+0x10/0x1c
[2.426195] ti_am3359-tscadc: probe of 4021.tscadc failed with error -1
>> Signed-off-by: Vignesh R
>> ---
>> drivers/mfd/ti_am335x_tscadc.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
>> index c2d47d78705b..ee08af34f81d 100644
>> --- a/drivers/mfd/ti_am335x_tscadc.c
>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>> @@ -248,7 +248,8 @@ static int ti_tscadc_probe(struct platform_device
>> *pdev)
>> if (tsc_wires > 0) {
>> tscadc->tsc_cell = tscadc->used_cells;
>> cell = >cells[tscadc->used_cells++];
>> -cell->name = "TI-am335x-tsc";
>> +cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>> +dev_name(>dev), "tsc");
>> cell->of_compatible = "ti,am3359-tsc";
>> cell->platform_data =
>> cell->pdata_size = sizeof(tscadc);
>> @@ -258,7 +259,8 @@ static int ti_tscadc_probe(struct platform_device
>> *pdev)
>> if (adc_channels > 0) {
>> tscadc->adc_cell = tscadc->used_cells;
>> cell = >cells[tscadc->used_cells++];
>> -cell->name = "TI-am335x-adc";
>> +cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
>> +dev_name(>dev), "adc");
>> cell->of_compatible = "ti,am3359-adc";
>> cell->platform_data =
>> cell->pdata_size = sizeof(tscadc);
>
--
Regards
Vignesh
Re: [PATCH 4.14 32/62] i2c: omap: Enable for ARCH_K3
Hi Greg,
On 26/11/18 4:21 PM, Greg Kroah-Hartman wrote:
> 4.14-stable review patch. If anyone has any objections, please let me know.
This patch depends on c77245722fb4 ("arm64: Add support for TI's K3
Multicore SoC architecture") which adds ARCH_K3 Kconfig symbol and
merged to mainline in v4.19. Since I don't see c77245722fb4 in
stable tree, could you please drop this patch from _all prior versions_
i.e 4.14, 4.9, 4.4 and 3.18. Thanks!
>
> --
>
> [ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ]
>
> Allow I2C_OMAP to be built for K3 platforms.
>
> Signed-off-by: Vignesh R
> Reviewed-by: Grygorii Strashko
> Signed-off-by: Wolfram Sang
> Signed-off-by: Sasha Levin
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 45a3f3ca29b3..75ea367ffd83 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -759,7 +759,7 @@ config I2C_OCORES
>
> config I2C_OMAP
> tristate "OMAP I2C adapter"
> - depends on ARCH_OMAP
> + depends on ARCH_OMAP || ARCH_K3
> default y if MACH_OMAP_H3 || MACH_OMAP_OSK
> help
> If you say yes to this option, support will be included for the
>
--
Regards
Vignesh
Re: [PATCH 4.14 32/62] i2c: omap: Enable for ARCH_K3
Hi Greg,
On 26/11/18 4:21 PM, Greg Kroah-Hartman wrote:
> 4.14-stable review patch. If anyone has any objections, please let me know.
This patch depends on c77245722fb4 ("arm64: Add support for TI's K3
Multicore SoC architecture") which adds ARCH_K3 Kconfig symbol and
merged to mainline in v4.19. Since I don't see c77245722fb4 in
stable tree, could you please drop this patch from _all prior versions_
i.e 4.14, 4.9, 4.4 and 3.18. Thanks!
>
> --
>
> [ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ]
>
> Allow I2C_OMAP to be built for K3 platforms.
>
> Signed-off-by: Vignesh R
> Reviewed-by: Grygorii Strashko
> Signed-off-by: Wolfram Sang
> Signed-off-by: Sasha Levin
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 45a3f3ca29b3..75ea367ffd83 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -759,7 +759,7 @@ config I2C_OCORES
>
> config I2C_OMAP
> tristate "OMAP I2C adapter"
> - depends on ARCH_OMAP
> + depends on ARCH_OMAP || ARCH_K3
> default y if MACH_OMAP_H3 || MACH_OMAP_OSK
> help
> If you say yes to this option, support will be included for the
>
--
Regards
Vignesh
Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions
On 20/11/18 4:07 PM, Tero Kristo wrote: > On 20/11/2018 12:09, Vignesh R wrote: >> On 19/11/18 12:49 PM, Tero Kristo wrote: >>> On 17/11/2018 18:05, Nishanth Menon wrote: >>>> On 11:31-20181113, Vignesh R wrote: >>>>> The dt-bindings header for TI K3 AM6 SoCs define a set of macros for >>>> >> [...] >>>> >>>> Thanks for reducing the combinations down to the minimum needed. We can >>>> worry about the DS and isolation bits when we have a real user for >>>> them. >>>> >>>> Acked-by: Nishanth Menon >>>> >>>> Tero: v4.21-rc1 perhaps ? >>>> >>> >>> Yeah, looks fine, queueing up for 4.21. >>> >> >> Thank you all for the review! >> >> Tero, >> >> Is there a branch with these patches that I can use as base for my next >> set of DT patches? > > Don't have a branch for these atm, but I can create one if you need it. Yes, that would be great. Thanks! -- Regards Vignesh
Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions
On 20/11/18 4:07 PM, Tero Kristo wrote: > On 20/11/2018 12:09, Vignesh R wrote: >> On 19/11/18 12:49 PM, Tero Kristo wrote: >>> On 17/11/2018 18:05, Nishanth Menon wrote: >>>> On 11:31-20181113, Vignesh R wrote: >>>>> The dt-bindings header for TI K3 AM6 SoCs define a set of macros for >>>> >> [...] >>>> >>>> Thanks for reducing the combinations down to the minimum needed. We can >>>> worry about the DS and isolation bits when we have a real user for >>>> them. >>>> >>>> Acked-by: Nishanth Menon >>>> >>>> Tero: v4.21-rc1 perhaps ? >>>> >>> >>> Yeah, looks fine, queueing up for 4.21. >>> >> >> Thank you all for the review! >> >> Tero, >> >> Is there a branch with these patches that I can use as base for my next >> set of DT patches? > > Don't have a branch for these atm, but I can create one if you need it. Yes, that would be great. Thanks! -- Regards Vignesh
Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions
On 19/11/18 12:49 PM, Tero Kristo wrote: > On 17/11/2018 18:05, Nishanth Menon wrote: >> On 11:31-20181113, Vignesh R wrote: >>> The dt-bindings header for TI K3 AM6 SoCs define a set of macros for >> [...] >> >> Thanks for reducing the combinations down to the minimum needed. We can >> worry about the DS and isolation bits when we have a real user for them. >> >> Acked-by: Nishanth Menon >> >> Tero: v4.21-rc1 perhaps ? >> > > Yeah, looks fine, queueing up for 4.21. > Thank you all for the review! Tero, Is there a branch with these patches that I can use as base for my next set of DT patches? -- Regards Vignesh
Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions
On 19/11/18 12:49 PM, Tero Kristo wrote: > On 17/11/2018 18:05, Nishanth Menon wrote: >> On 11:31-20181113, Vignesh R wrote: >>> The dt-bindings header for TI K3 AM6 SoCs define a set of macros for >> [...] >> >> Thanks for reducing the combinations down to the minimum needed. We can >> worry about the DS and isolation bits when we have a real user for them. >> >> Acked-by: Nishanth Menon >> >> Tero: v4.21-rc1 perhaps ? >> > > Yeah, looks fine, queueing up for 4.21. > Thank you all for the review! Tero, Is there a branch with these patches that I can use as base for my next set of DT patches? -- Regards Vignesh
[PATCH] dt-bindings: ti-tsc-adc: Add new compatible for AM654 SoCs
AM654 SoCs has ADC IP which is similar to AM335x. Add new compatible to handle AM654 SoCs. Also, it seems that existing compatible strings used in the kernel DTs were never documented. So, document them now. Signed-off-by: Vignesh R --- .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt index b1163bf97146..aad5e34965eb 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt @@ -2,7 +2,12 @@ ~~ Required properties: +- mfd + compatible: Should be + "ti,am3359-tscadc" for AM335x/AM437x SoCs + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs - child "tsc" + compatible: Should be "ti,am3359-tsc". ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen support on the platform. ti,x-plate-resistance: X plate resistance @@ -25,6 +30,9 @@ Required properties: AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. XP = 0, XN = 1, YP = 2, YN = 3. - child "adc" + compatible: Should be + "ti,am3359-adc" for AM335x/AM437x SoCs + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs ti,adc-channels: List of analog inputs available for ADC. AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. -- 2.19.1
[PATCH] dt-bindings: ti-tsc-adc: Add new compatible for AM654 SoCs
AM654 SoCs has ADC IP which is similar to AM335x. Add new compatible to handle AM654 SoCs. Also, it seems that existing compatible strings used in the kernel DTs were never documented. So, document them now. Signed-off-by: Vignesh R --- .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt index b1163bf97146..aad5e34965eb 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt @@ -2,7 +2,12 @@ ~~ Required properties: +- mfd + compatible: Should be + "ti,am3359-tscadc" for AM335x/AM437x SoCs + "ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs - child "tsc" + compatible: Should be "ti,am3359-tsc". ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen support on the platform. ti,x-plate-resistance: X plate resistance @@ -25,6 +30,9 @@ Required properties: AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. XP = 0, XN = 1, YP = 2, YN = 3. - child "adc" + compatible: Should be + "ti,am3359-adc" for AM335x/AM437x SoCs + "ti,am654-adc", "ti,am3359-adc" for AM654 SoCs ti,adc-channels: List of analog inputs available for ADC. AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. -- 2.19.1
[PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to VREFP and VREFN
respectively in STEP_CONFIGx register.
Without these changes, there may be variation of as much as ~2% in the
ADC's digital output which is bad for precise measurement.
Signed-off-by: Vignesh R
---
drivers/iio/adc/ti_am335x_adc.c | 5 -
include/linux/mfd/ti_am335x_tscadc.h | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index cafb1dcadc48..9d984f2a8ba7 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
stepconfig |= STEPCONFIG_MODE_SWCNT;
tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
- stepconfig | STEPCONFIG_INP(chan));
+ stepconfig | STEPCONFIG_INP(chan) |
+ STEPCONFIG_INM_ADCREFM |
+ STEPCONFIG_RFP_VREFP |
+ STEPCONFIG_RFM_VREFN);
if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
dev_warn(dev, "chan %d open delay truncating to
0x3\n",
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index b9a53e013bff..483168403ae5 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -78,6 +78,8 @@
#define STEPCONFIG_YNN BIT(8)
#define STEPCONFIG_XNP BIT(9)
#define STEPCONFIG_YPN BIT(10)
+#define STEPCONFIG_RFP(val)((val) << 12)
+#define STEPCONFIG_RFP_VREFP (0x3 << 12)
#define STEPCONFIG_INM_MASK(0xF << 15)
#define STEPCONFIG_INM(val)((val) << 15)
#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
@@ -86,6 +88,8 @@
#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
#define STEPCONFIG_FIFO1 BIT(26)
+#define STEPCONFIG_RFM(val)((val) << 23)
+#define STEPCONFIG_RFM_VREFN (0x3 << 23)
/* Delay register */
#define STEPDELAY_OPEN_MASK(0x3 << 0)
--
2.19.1
[PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to VREFP and VREFN
respectively in STEP_CONFIGx register.
Without these changes, there may be variation of as much as ~2% in the
ADC's digital output which is bad for precise measurement.
Signed-off-by: Vignesh R
---
drivers/iio/adc/ti_am335x_adc.c | 5 -
include/linux/mfd/ti_am335x_tscadc.h | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index cafb1dcadc48..9d984f2a8ba7 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
stepconfig |= STEPCONFIG_MODE_SWCNT;
tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
- stepconfig | STEPCONFIG_INP(chan));
+ stepconfig | STEPCONFIG_INP(chan) |
+ STEPCONFIG_INM_ADCREFM |
+ STEPCONFIG_RFP_VREFP |
+ STEPCONFIG_RFM_VREFN);
if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
dev_warn(dev, "chan %d open delay truncating to
0x3\n",
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index b9a53e013bff..483168403ae5 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -78,6 +78,8 @@
#define STEPCONFIG_YNN BIT(8)
#define STEPCONFIG_XNP BIT(9)
#define STEPCONFIG_YPN BIT(10)
+#define STEPCONFIG_RFP(val)((val) << 12)
+#define STEPCONFIG_RFP_VREFP (0x3 << 12)
#define STEPCONFIG_INM_MASK(0xF << 15)
#define STEPCONFIG_INM(val)((val) << 15)
#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
@@ -86,6 +88,8 @@
#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
#define STEPCONFIG_FIFO1 BIT(26)
+#define STEPCONFIG_RFM(val)((val) << 23)
+#define STEPCONFIG_RFM_VREFN (0x3 << 23)
/* Delay register */
#define STEPDELAY_OPEN_MASK(0x3 << 0)
--
2.19.1
[PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
Provide unique names for child mfd cells, this is required in order to
support registering of multiple instances of same ti_am335x_tscadc IP.
Signed-off-by: Vignesh R
---
drivers/mfd/ti_am335x_tscadc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index c2d47d78705b..ee08af34f81d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -248,7 +248,8 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
if (tsc_wires > 0) {
tscadc->tsc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
- cell->name = "TI-am335x-tsc";
+ cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+ dev_name(>dev), "tsc");
cell->of_compatible = "ti,am3359-tsc";
cell->platform_data =
cell->pdata_size = sizeof(tscadc);
@@ -258,7 +259,8 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
if (adc_channels > 0) {
tscadc->adc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
- cell->name = "TI-am335x-adc";
+ cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+ dev_name(>dev), "adc");
cell->of_compatible = "ti,am3359-adc";
cell->platform_data =
cell->pdata_size = sizeof(tscadc);
--
2.19.1
[PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
Provide unique names for child mfd cells, this is required in order to
support registering of multiple instances of same ti_am335x_tscadc IP.
Signed-off-by: Vignesh R
---
drivers/mfd/ti_am335x_tscadc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index c2d47d78705b..ee08af34f81d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -248,7 +248,8 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
if (tsc_wires > 0) {
tscadc->tsc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
- cell->name = "TI-am335x-tsc";
+ cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+ dev_name(>dev), "tsc");
cell->of_compatible = "ti,am3359-tsc";
cell->platform_data =
cell->pdata_size = sizeof(tscadc);
@@ -258,7 +259,8 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
if (adc_channels > 0) {
tscadc->adc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
- cell->name = "TI-am335x-adc";
+ cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+ dev_name(>dev), "adc");
cell->of_compatible = "ti,am3359-adc";
cell->platform_data =
cell->pdata_size = sizeof(tscadc);
--
2.19.1
[PATCH 0/2] tscadc: Couple of fixes
Couple of fixes for tscadc drivers that I found while adding support for new SoC. Patches are standalone and can go via individual domain trees. Vignesh R (2): mfd: ti_am335x_tscadc: Provide unique name for child mfd cells iio: adc: ti_am335x_tscadc: Improve accuracy of measurement drivers/iio/adc/ti_am335x_adc.c | 5 - drivers/mfd/ti_am335x_tscadc.c | 6 -- include/linux/mfd/ti_am335x_tscadc.h | 4 3 files changed, 12 insertions(+), 3 deletions(-) -- 2.19.1
[PATCH 0/2] tscadc: Couple of fixes
Couple of fixes for tscadc drivers that I found while adding support for new SoC. Patches are standalone and can go via individual domain trees. Vignesh R (2): mfd: ti_am335x_tscadc: Provide unique name for child mfd cells iio: adc: ti_am335x_tscadc: Improve accuracy of measurement drivers/iio/adc/ti_am335x_adc.c | 5 - drivers/mfd/ti_am335x_tscadc.c | 6 -- include/linux/mfd/ti_am335x_tscadc.h | 4 3 files changed, 12 insertions(+), 3 deletions(-) -- 2.19.1
Re: [PATCH AUTOSEL 4.18 39/59] i2c: omap: Enable for ARCH_K3
Hi,
On 15/11/18 3:53 AM, Sasha Levin wrote:
> From: Vignesh R
>
> [ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ]
This patch depends on c77245722fb4 ("arm64: Add support for TI's K3
Multicore SoC architecture") which adds ARCH_K3 Kconfig symbol and
merged to mainline in v4.19. Since I don't see c77245722fb4 in
stable tree, please drop this commit from stable queues prior to v4.19
(4.18, 4.14, 4.9, 4.4 and 3.18).
>
> Allow I2C_OMAP to be built for K3 platforms.
>
> Signed-off-by: Vignesh R
> Reviewed-by: Grygorii Strashko
> Signed-off-by: Wolfram Sang
> Signed-off-by: Sasha Levin
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 4f8df2ec87b1..fb3a3707a66e 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -754,7 +754,7 @@ config I2C_OCORES
>
> config I2C_OMAP
> tristate "OMAP I2C adapter"
> - depends on ARCH_OMAP
> + depends on ARCH_OMAP || ARCH_K3
> default y if MACH_OMAP_H3 || MACH_OMAP_OSK
> help
> If you say yes to this option, support will be included for the
>
--
Regards
Vignesh
Re: [PATCH AUTOSEL 4.18 39/59] i2c: omap: Enable for ARCH_K3
Hi,
On 15/11/18 3:53 AM, Sasha Levin wrote:
> From: Vignesh R
>
> [ Upstream commit 5b277402deac0691226a947df71c581686bd4020 ]
This patch depends on c77245722fb4 ("arm64: Add support for TI's K3
Multicore SoC architecture") which adds ARCH_K3 Kconfig symbol and
merged to mainline in v4.19. Since I don't see c77245722fb4 in
stable tree, please drop this commit from stable queues prior to v4.19
(4.18, 4.14, 4.9, 4.4 and 3.18).
>
> Allow I2C_OMAP to be built for K3 platforms.
>
> Signed-off-by: Vignesh R
> Reviewed-by: Grygorii Strashko
> Signed-off-by: Wolfram Sang
> Signed-off-by: Sasha Levin
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 4f8df2ec87b1..fb3a3707a66e 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -754,7 +754,7 @@ config I2C_OCORES
>
> config I2C_OMAP
> tristate "OMAP I2C adapter"
> - depends on ARCH_OMAP
> + depends on ARCH_OMAP || ARCH_K3
> default y if MACH_OMAP_H3 || MACH_OMAP_OSK
> help
> If you say yes to this option, support will be included for the
>
--
Regards
Vignesh
Re: [PATCH] mtd: spi-nor: Fix Cadence QSPI page fault kernel panic
Hi,
On 13/11/18 11:02 PM, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
> The current Cadence QSPI driver caused a kernel panic sporadically
> when writing to QSPI. The problem was caused by writing more bytes
> than needed because the QSPI operated on 4 bytes at a time.
>
> [ 11.202044] Unable to handle kernel paging request at virtual address
> bffd3000
> [ 11.209254] pgd = e463054d
> [ 11.211948] [bffd3000] *pgd=2fffb811, *pte=, *ppte=
> [ 11.218202] Internal error: Oops: 7 [#1] SMP ARM
> [ 11.222797] Modules linked in:
> [ 11.225844] CPU: 1 PID: 1317 Comm: systemd-hwdb Not tainted
> 4.17.7-d0c45cd44a8f
> [ 11.235796] Hardware name: Altera SOCFPGA Arria10
> [ 11.240487] PC is at __raw_writesl+0x70/0xd4
> [ 11.244741] LR is at cqspi_write+0x1a0/0x2cc
>
> On a page boundary limit the number of bytes copied from the tx buffer
> to remain within the page.
>
> This patch uses a temporary buffer to hold the 4 bytes to write and then
> copies only the bytes required from the tx buffer. A min() function is
> used to limit the length to prevent buffer indexing overflows.
>
> Reported-by: Adrian Amborzewicz
> Signed-off-by: Thor Thayer
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> index d846428ef038..3659d94b4d2f 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -644,9 +644,23 @@ static int cqspi_indirect_write_execute(struct spi_nor
> *nor, loff_t to_addr,
> ndelay(cqspi->wr_delay);
>
> while (remaining > 0) {
> + size_t write_words, mod_bytes;
> +
> write_bytes = remaining > page_size ? page_size : remaining;
> - iowrite32_rep(cqspi->ahb_base, txbuf,
> - DIV_ROUND_UP(write_bytes, 4));
> + write_words = write_bytes / 4;
> + mod_bytes = write_bytes % 4;
> + /* Write 4 bytes at a time then single bytes. */
> + if (write_words) {
> + iowrite32_rep(cqspi->ahb_base, txbuf, write_words);
> + txbuf += (write_words * 4);
> + }
> + if (mod_bytes) {
> + unsigned int temp = 0x;
> +
> + memcpy(, txbuf, min(sizeof(temp), mod_bytes));
Sorry, I dont understand why min() is required here since:
mod_bytes = write_bytes % 4;
Doesn't that ensure mod_bytes < sizeof(temp)?
> + iowrite32(temp, cqspi->ahb_base);
> + txbuf += mod_bytes;
> + }
>
> if (!wait_for_completion_timeout(>transfer_complete,
> msecs_to_jiffies(CQSPI_TIMEOUT_MS))) {
> @@ -655,7 +669,6 @@ static int cqspi_indirect_write_execute(struct spi_nor
> *nor, loff_t to_addr,
> goto failwr;
> }
>
> - txbuf += write_bytes;
> remaining -= write_bytes;
>
> if (remaining > 0)
>
--
Regards
Vignesh
Re: [PATCH] mtd: spi-nor: Fix Cadence QSPI page fault kernel panic
Hi,
On 13/11/18 11:02 PM, thor.tha...@linux.intel.com wrote:
> From: Thor Thayer
>
> The current Cadence QSPI driver caused a kernel panic sporadically
> when writing to QSPI. The problem was caused by writing more bytes
> than needed because the QSPI operated on 4 bytes at a time.
>
> [ 11.202044] Unable to handle kernel paging request at virtual address
> bffd3000
> [ 11.209254] pgd = e463054d
> [ 11.211948] [bffd3000] *pgd=2fffb811, *pte=, *ppte=
> [ 11.218202] Internal error: Oops: 7 [#1] SMP ARM
> [ 11.222797] Modules linked in:
> [ 11.225844] CPU: 1 PID: 1317 Comm: systemd-hwdb Not tainted
> 4.17.7-d0c45cd44a8f
> [ 11.235796] Hardware name: Altera SOCFPGA Arria10
> [ 11.240487] PC is at __raw_writesl+0x70/0xd4
> [ 11.244741] LR is at cqspi_write+0x1a0/0x2cc
>
> On a page boundary limit the number of bytes copied from the tx buffer
> to remain within the page.
>
> This patch uses a temporary buffer to hold the 4 bytes to write and then
> copies only the bytes required from the tx buffer. A min() function is
> used to limit the length to prevent buffer indexing overflows.
>
> Reported-by: Adrian Amborzewicz
> Signed-off-by: Thor Thayer
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> index d846428ef038..3659d94b4d2f 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -644,9 +644,23 @@ static int cqspi_indirect_write_execute(struct spi_nor
> *nor, loff_t to_addr,
> ndelay(cqspi->wr_delay);
>
> while (remaining > 0) {
> + size_t write_words, mod_bytes;
> +
> write_bytes = remaining > page_size ? page_size : remaining;
> - iowrite32_rep(cqspi->ahb_base, txbuf,
> - DIV_ROUND_UP(write_bytes, 4));
> + write_words = write_bytes / 4;
> + mod_bytes = write_bytes % 4;
> + /* Write 4 bytes at a time then single bytes. */
> + if (write_words) {
> + iowrite32_rep(cqspi->ahb_base, txbuf, write_words);
> + txbuf += (write_words * 4);
> + }
> + if (mod_bytes) {
> + unsigned int temp = 0x;
> +
> + memcpy(, txbuf, min(sizeof(temp), mod_bytes));
Sorry, I dont understand why min() is required here since:
mod_bytes = write_bytes % 4;
Doesn't that ensure mod_bytes < sizeof(temp)?
> + iowrite32(temp, cqspi->ahb_base);
> + txbuf += mod_bytes;
> + }
>
> if (!wait_for_completion_timeout(>transfer_complete,
> msecs_to_jiffies(CQSPI_TIMEOUT_MS))) {
> @@ -655,7 +669,6 @@ static int cqspi_indirect_write_execute(struct spi_nor
> *nor, loff_t to_addr,
> goto failwr;
> }
>
> - txbuf += write_bytes;
> remaining -= write_bytes;
>
> if (remaining > 0)
>
--
Regards
Vignesh
Re: [PATCH v3 0/7] spi: add support for octo mode
Hi Yogesh On 23/10/18 3:07 PM, Yogesh Narayan Gaur wrote: > Add support for octo mode IO data transfer. > Micron flash, mt35xu512aba, supports octal mode data transfer and > NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx). > > Patch series > * Add support for octo mode flags and parsing of same in spi driver. > * Add parsing logic for spi-mem framework and m25p80.c device file. > * Add opcodes for octo I/O commands in spi-nor framework, Read and Write > proto for (1-1-8/1-8-8) mode. > Opcodes are added as per octal data IO commands required for mt35xu512aba > [1] flash. > * Add mode bit required for octo mode in nxp-fspi driver [2]. > * Define binding property 'spi-rx/tx-bus-width' for LX2160ARDB target [2]. > You may have to rebase this series to avoid conflicts with recent spi.h changes. Also, I suggest merging patches in [1] with this series if you plan to post another version so that all bits are at one place. Regards Vignesh > Cherry pick below 2 patches (from: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git): > c639f871febe6667d9afce28108c634e5636c735 spi: spi-mem: Fix inverted logic > in op sanity check > db122eb8a749a1eff038f9a282c620ab16c4be1d spi: spi-mem: Add extra sanity > checks on the op param > > Tested on LX2160ARDB target with nxp-fspi driver, below are > Read performance number of 1-1-1 and 1-1-8 read protocol. > > root@lxxx:~# cat /proc/mtd > dev:size erasesize name > mtd0: 0400 1000 "spi0.0" > mtd1: 0400 1000 "spi0.1" > root@lxxx:~# time mtd_debug read /dev/mtd0 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m2.792s > user0m0.000s > sys 0m2.790s > root@lxxx:~# time mtd_debug read /dev/mtd1 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m0.441s > user0m0.000s > sys 0m0.440s > root@ls1012ardb:~# > > Flash device MTD0 configured in 1-1-1 protocol. > Flash device MTD1 configured in 1-1-8 protocol. > > [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70384 > [2] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=72181 > > Yogesh Gaur (7): > spi: add support for octo mode I/O data transfer > spi: spi-mem: add support for octo mode I/O data transfer > mtd: spi-nor: add opcodes for octo Read/Write commands > mtd: spi-nor: add octo read flag for flash mt35xu512aba > mtd: m25p80: add support of octo mode I/O transfer > spi: nxp-fspi: add octo mode flag bit for octal support > arm64: dts: lx2160a: update fspi node > > Changes for v3: > - Add octo mode support in spi_setup(). > - Rename all patches with 'octal' string modified as 'octo'. > Changes for v2: > - Incorporated review comments of Boris and Vignesh. > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 > drivers/mtd/devices/m25p80.c | 9 - > drivers/mtd/spi-nor/spi-nor.c | 15 ++- > drivers/spi/spi-mem.c | 9 - > drivers/spi/spi-nxp-fspi.c| 4 ++-- > drivers/spi/spi.c | 12 ++-- > include/linux/mtd/spi-nor.h | 8 > include/linux/spi/spi.h | 2 ++ > 8 files changed, 56 insertions(+), 7 deletions(-) > -- Regards Vignesh
Re: [PATCH v3 0/7] spi: add support for octo mode
Hi Yogesh On 23/10/18 3:07 PM, Yogesh Narayan Gaur wrote: > Add support for octo mode IO data transfer. > Micron flash, mt35xu512aba, supports octal mode data transfer and > NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx). > > Patch series > * Add support for octo mode flags and parsing of same in spi driver. > * Add parsing logic for spi-mem framework and m25p80.c device file. > * Add opcodes for octo I/O commands in spi-nor framework, Read and Write > proto for (1-1-8/1-8-8) mode. > Opcodes are added as per octal data IO commands required for mt35xu512aba > [1] flash. > * Add mode bit required for octo mode in nxp-fspi driver [2]. > * Define binding property 'spi-rx/tx-bus-width' for LX2160ARDB target [2]. > You may have to rebase this series to avoid conflicts with recent spi.h changes. Also, I suggest merging patches in [1] with this series if you plan to post another version so that all bits are at one place. Regards Vignesh > Cherry pick below 2 patches (from: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git): > c639f871febe6667d9afce28108c634e5636c735 spi: spi-mem: Fix inverted logic > in op sanity check > db122eb8a749a1eff038f9a282c620ab16c4be1d spi: spi-mem: Add extra sanity > checks on the op param > > Tested on LX2160ARDB target with nxp-fspi driver, below are > Read performance number of 1-1-1 and 1-1-8 read protocol. > > root@lxxx:~# cat /proc/mtd > dev:size erasesize name > mtd0: 0400 1000 "spi0.0" > mtd1: 0400 1000 "spi0.1" > root@lxxx:~# time mtd_debug read /dev/mtd0 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m2.792s > user0m0.000s > sys 0m2.790s > root@lxxx:~# time mtd_debug read /dev/mtd1 0x0 0x100 0read > Copied 16777216 bytes from address 0x in flash to 0read > > real0m0.441s > user0m0.000s > sys 0m0.440s > root@ls1012ardb:~# > > Flash device MTD0 configured in 1-1-1 protocol. > Flash device MTD1 configured in 1-1-8 protocol. > > [1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=70384 > [2] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=72181 > > Yogesh Gaur (7): > spi: add support for octo mode I/O data transfer > spi: spi-mem: add support for octo mode I/O data transfer > mtd: spi-nor: add opcodes for octo Read/Write commands > mtd: spi-nor: add octo read flag for flash mt35xu512aba > mtd: m25p80: add support of octo mode I/O transfer > spi: nxp-fspi: add octo mode flag bit for octal support > arm64: dts: lx2160a: update fspi node > > Changes for v3: > - Add octo mode support in spi_setup(). > - Rename all patches with 'octal' string modified as 'octo'. > Changes for v2: > - Incorporated review comments of Boris and Vignesh. > > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 > drivers/mtd/devices/m25p80.c | 9 - > drivers/mtd/spi-nor/spi-nor.c | 15 ++- > drivers/spi/spi-mem.c | 9 - > drivers/spi/spi-nxp-fspi.c| 4 ++-- > drivers/spi/spi.c | 12 ++-- > include/linux/mtd/spi-nor.h | 8 > include/linux/spi/spi.h | 2 ++ > 8 files changed, 56 insertions(+), 7 deletions(-) > -- Regards Vignesh
