| Message ID | 1636448488-14158-1-git-send-email-lh.kuo@sunplus.com |
|---|---|
| Headers | show |
| Series | Add SPI control driver for Sunplus SP7021 SoC | expand |
On Tue, Nov 09, 2021 at 05:01:27PM +0800, LH.Kuo wrote: A lot of my previous feedback on this driver still applies, while some of the issues have been addressed most of the major structural issues continue to apply here. A lot of the code is replicating code from the core or is really hard to explain, it's hard to see anything super unusual with the hardware here that would require such unusual code. Please don't ignore review comments, people are generally making them for a reason and are likely to have the same concerns if issues remain unaddressed. Having to repeat the same comments can get repetitive and make people question the value of time spent reviewing. If you disagree with the review comments that's fine but you need to reply and discuss your concerns so that the reviewer can understand your decisions. > +static void sp7021_spi_set_cs(struct spi_device *_s, bool _on) > +{ > + if (_s->mode & SPI_NO_CS) > + return; > + if (!(_s->cs_gpiod)) > + return; > + dev_dbg(&(_s->dev), "%d gpiod:%d", _on, desc_to_gpio(_s->cs_gpiod)); > + if (_s->mode & SPI_CS_HIGH) > + _on = !_on; > + gpiod_set_value_cansleep(_s->cs_gpiod, _on); > +} This is *still* open coding a GPIO chip select, to repeat what I said last time this is not OK - use the core facilities to avoid introducing bugs like double application of SPI_CS_HIGH you have here. > +// spi slave irq handler > +static irqreturn_t sp7021_spi_sla_irq(int _irq, void *_dev) > +{ > + struct sp7021_spi_ctlr *pspim = (struct sp7021_spi_ctlr *)_dev; If you need this cast something is very wrong, do you need it? > +int sp7021_spi_sla_rw(struct spi_device *_s, struct spi_transfer *_t, int RW_phase) Please use the normal kernel coding style, using _s for parameter names or mixed case symbol names isn't normal for the kernel. There's also issues with line lengths over 80 columns all over, while it's not a strict limit it's still good try to keep things to a reasonable length. > + if (RW_phase == SP7021_SLA_WRITE) { This looks like a switch statement, though given how little code is shared it's not clear why this is all in one function. > + if (_t->tx_dma == pspim->tx_dma_phy_base) > + memcpy(pspim->tx_dma_vir_base, _t->tx_buf, _t->len); Why are we copying data into a DMA transfer buffer, doesn't this defeat the point of DMA? I'd expect to DMA data directly. I'd also expect some synchronisation operations to ensure that everything has a consistent view of the memory. > +// spi master irq handler > +static irqreturn_t sp7021_spi_mas_irq_dma(int _irq, void *_dev) > +{ > + struct sp7021_spi_ctlr *pspim = (struct sp7021_spi_ctlr *)_dev; > + > + spin_lock_irq(&pspim->lock); Why are we using spin_lock_irq() when we're already in an interrupt handler? > + } > +} > +void sp7021spi_wb(struct sp7021_spi_ctlr *_m, u8 _len) Blank lines between functions. > +fin_irq: > + if (isrdone) > + complete(&pspim->isr_done); > + spin_unlock_irqrestore(&pspim->lock, flags); > + return IRQ_HANDLED; > +} This unconditionally reports IRQ_HANDLED even if we didn't actually see any interrupt status flagged, this will break shared interrupts and reduce the ability of the interrupt core to handle errors. > + for (i = 0; i < transfers_cnt; i++) { > + if (t->tx_buf) > + memcpy(&pspim->tx_data_buf[data_len], t->tx_buf, t->len); > + if (t->rx_buf) > + xfer_rx = true; > + data_len += t->len; > + t = list_entry(t->transfer_list.next, struct spi_transfer, transfer_list); > + } This is still copying all data for no apparent reason as highlighted last time. > + dev_dbg(&(_c->dev), "data_len %d xfer_rx %d", data_len, xfer_rx); > + > + // set SPI FIFO data for full duplex (SPI_FD fifo_data) 91.13 > + if (pspim->tx_cur_len < data_len) { > + len_temp = min(pspim->data_unit, data_len); > + sp7021spi_wb(pspim, len_temp); > + } Is the device full duplex or half duplex? The code immediately above this treats both transmit and recieve buffers as optional. If the device does actually need to be full duplex then the driver should flag it as such. > +// called when child device is registering on the bus > +static int sp7021_spi_dev_setup(struct spi_device *_s) > +{ > + struct sp7021_spi_ctlr *pspim = spi_controller_get_devdata(_s->controller); > + int ret; > + > + ret = pm_runtime_get_sync(pspim->dev); > + if (ret < 0) > + return 0; > + > + pm_runtime_put(pspim->dev); > + > + return 0; > + > +} This function does nothing except bounce the power on the device, this is obviously not useful and should be removed. > +static int sp7021_spi_controller_unprepare_message(struct spi_controller *_c, > + struct spi_message *msg) > +{ > + return 0; > +} Remove empty functions. > +static size_t sp7021_spi_max_length(struct spi_device *spi) > +{ > + return SP7021_SPI_MSG_SIZE; > +} Is there any actual limit in the hardware? This looks very much like it's a completely artificial limit in the driver for no obvious reason. > +static int sp7021_spi_mas_transfer_one_message(struct spi_controller *_c, struct spi_message *m) > +{ > + struct sp7021_spi_ctlr *pspim = spi_master_get_devdata(_c); > + struct spi_device *spi = m->spi; > + unsigned int xfer_cnt = 0, total_len = 0; > + bool start_xfer = false; > + struct spi_transfer *xfer, *first_xfer = NULL; > + int ret; > + bool keep_cs = false; > + > + pm_runtime_get_sync(pspim->dev); To repeat the feedback from last time do not open code runtime PM, use the core support. > + sp7021_spi_set_cs(spi, true); > + > + list_for_each_entry(xfer, &m->transfers, transfer_list) { > + if (!first_xfer) > + first_xfer = xfer; > + total_len += xfer->len; To further repeat my prior feedback I can't see any reason why this driver doesn't just use transfer_one().
On 11/9/21 1:01 AM, LH.Kuo wrote: > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 596705d..30ce0ed 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -866,6 +866,17 @@ config SPI_SUN6I > help > This enables using the SPI controller on the Allwinner A31 SoCs. > > +config SPI_SUNPLUS_SP7021 > + tristate "Sunplus SP7021 SPI controller" > + depends on SOC_SP7021 > + help > + This enable Sunplus SP7021 spi controller driver on the SP7021 SoCs. enables the Sunplus SP021 SPI > + This driver can also be built as a module. If so, the module will be > + called as spi-sunplus-sp7021. > + > + If you have a Sunplus SP7021 platform say Y here. have a Sunplus (i.e., drop one space) > + If unsure, say N.
On 11/9/21 9:39 PM, Lh Kuo 郭力豪 wrote: > Hi > >> -----Original Message----- >> From: Randy Dunlap <rdunlap@infradead.org> >> Sent: Wednesday, November 10, 2021 12:55 AM >> To: LH.Kuo <lhjeff911@gmail.com>; p.zabel@pengutronix.de; >> broonie@kernel.org; robh+dt@kernel.org; linux-spi@vger.kernel.org; >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org >> Cc: dvorkin@tibbo.com; qinjian@cqplus1.com; Wells Lu 呂芳騰 >> <wells.lu@sunplus.com>; Lh Kuo 郭力豪 <lh.Kuo@sunplus.com> >> Subject: Re: [PATCH v2 1/2] SPI: Add SPI driver for Sunplus SP7021 >> >> On 11/9/21 1:01 AM, LH.Kuo wrote: >>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index >>> 596705d..30ce0ed 100644 >>> --- a/drivers/spi/Kconfig >>> +++ b/drivers/spi/Kconfig >>> @@ -866,6 +866,17 @@ config SPI_SUN6I >>> help >>> This enables using the SPI controller on the Allwinner A31 SoCs. >>> >>> +config SPI_SUNPLUS_SP7021 >>> + tristate "Sunplus SP7021 SPI controller" >>> + depends on SOC_SP7021 >>> + help >>> + This enable Sunplus SP7021 spi controller driver on the SP7021 SoCs. >> >> enables the Sunplus SP021 SPI >> >>> + This driver can also be built as a module. If so, the module will be >>> + called as spi-sunplus-sp7021. >>> + >>> + If you have a Sunplus SP7021 platform say Y here. >> >> have a Sunplus >> (i.e., drop one space) >> >>> + If unsure, say N. >> >> > > I will make change as below is it OK ? > > config SPI_SUNPLUS_SP7021 > tristate "Sunplus SP7021 SPI controller" > depends on SOC_SP7021 > help > This enable Sunplus SP7021 spi controller driver on the SP7021 SoCs. enables SPI > This driver can also be built as a module. If so, the module will be > called as spi-sunplus-sp7021. > > If you have a Sunplus SP7021 platform say Y here. drop one space: a Sunplus > > If unsure, say N. > >> -- >> ~Randy
On Wed, Nov 10, 2021 at 02:42:01AM +0000, Lh Kuo 郭力豪 wrote: Please don't send new patches in reply to old patches or serieses, this makes it harder for both people and tools to understand what is going on - it can bury things in mailboxes and make it difficult to keep track of what current patches are, both for the new patches and the old ones. > > This is *still* open coding a GPIO chip select, to repeat what I said last time > > this is not OK - use the core facilities to avoid introducing bugs like double > > application of SPI_CS_HIGH you have here. > I try to find some function can replay this part. > EX: > Spi.c -> spi_set_cs but it is not EXPORT_SYMBOL_GPL and it looks not fit in the driver > > Spi-gpio.c -> spi_gpio_chipselect it looks not fit in the driver. > > Sorry maybe i misunderstood this issue > > Or the problem is gpiod_set_value_cansleep can't be used in here ? > > Which function can I use for GPIO_CS? The same way other controllers do: by setting use_gpio_descriptors in the controller. The core will then request the GPIOs for the driver using the standard binding, this requires no further work on the part of the driver. > > > +// spi slave irq handler > > > +static irqreturn_t sp7021_spi_sla_irq(int _irq, void *_dev) { > > > + struct sp7021_spi_ctlr *pspim = (struct sp7021_spi_ctlr *)_dev; > > If you need this cast something is very wrong, do you need it? > So the vold* should be struct * spi_controller ?? No, interrupt handlers need to take an int and a void *. There should be no cast. > > > + if (RW_phase == SP7021_SLA_WRITE) { > > This looks like a switch statement, though given how little code is shared it's > > not clear why this is all in one function. > It is easy to check the flow and setting for me It's contributing to making the code hard for other people to follow. > > > + if (_t->tx_dma == pspim->tx_dma_phy_base) > > > + memcpy(pspim->tx_dma_vir_base, _t->tx_buf, _t->len); > > Why are we copying data into a DMA transfer buffer, doesn't this defeat the > > point of DMA? I'd expect to DMA data directly. I'd also expect some > > synchronisation operations to ensure that everything has a consistent view of > > the memory. > It only happens when tx_dma = pspim->tx_dma_phy_base > And if it can't get dma-addr or wrong case. I will set tx_dma = pspim->tx_dma_phy_base. What does that mean at a higher level - what is tx_dma here? Why does not being able to get an address to DMA mean that we need to memcpy() things? I can't see any reason for the memcpy() at all. > > > +// spi master irq handler > > > +static irqreturn_t sp7021_spi_mas_irq_dma(int _irq, void *_dev) { > > > + struct sp7021_spi_ctlr *pspim = (struct sp7021_spi_ctlr *)_dev; > > > + spin_lock_irq(&pspim->lock); > > Why are we using spin_lock_irq() when we're already in an interrupt handler? > Yes it is in interrupt handler Yes, I know it's an interrupt handler - to repeat my question why are we we using spin_lock_irq() in that case? > > > + return IRQ_HANDLED; > > > +} > > This unconditionally reports IRQ_HANDLED even if we didn't actually see any > > interrupt status flagged, this will break shared interrupts and reduce the ability > > of the interrupt core to handle errors. > Sorry I'm confuse. What should i do in this issue Report IRQ_NONE if there was no interrupts reported by the hardware. > > This is still copying all data for no apparent reason as highlighted last time. > It is difference case. It is in master mode and and can only be transmitted through FIFO > And It is transmitting for one message and I need collect the all tx data first. For what reason do you need to collect all the tx data? It really is not at all apparent from the code and seems especially unusual in the PIO case. > > Is the device full duplex or half duplex? The code immediately above this > > treats both transmit and recieve buffers as optional. If the device does > > actually need to be full duplex then the driver should flag it as such. > You mean set the flsg of should be struct * spi_controller in probe function > Ctlr-flags = SPI_CONTROLLER_FULL_DUPLEX right ? Yes. > > > +// called when child device is registering on the bus static int > > > +sp7021_spi_dev_setup(struct spi_device *_s) { > > > + struct sp7021_spi_ctlr *pspim = > > spi_controller_get_devdata(_s->controller); > > > + int ret; > > > + > > > + ret = pm_runtime_get_sync(pspim->dev); > > > + if (ret < 0) > > > + return 0; > > > + > > > + pm_runtime_get_sync(pspim->dev);; > > > + > > > + return 0; > > > + > > > +} > > This function does nothing except bounce the power on the device, this is > > obviously not useful and should be removed. > You mean set the auto_runtime_pm of should be struct * spi_controller in probe function > And remove pm_runtime_get_sync(pspim->dev); > pm_runtime_get_sync(pspim->dev); > even the pm_runtime in the probe should be remove . right ? You should only take a runtime reference for the period that it's actually needed. Taking one in probe and then not dropping it before the end of probe would defeat the point of having runtime PM. > > > +static size_t sp7021_spi_max_length(struct spi_device *spi) { > > > + return SP7021_SPI_MSG_SIZE; > > > +} > > Is there any actual limit in the hardware? This looks very much like it's a > > completely artificial limit in the driver for no obvious reason. > The limit of the hardware is only 255 bytes . But more user need more than the limit. > So I try to extend by software that is one reason use one message transfer and use CS-GPIO As ever *please* use the core features rather than open coding - if you specify a maximum transfer size the core already supports using a software controllable chip select to handle messages with transfers of arbatrary lengths. There is no need for the driver to do anything here other than providing a length, but that needs to be per transfer and not per message. In general if you're doing something that doesn't interact directly with the hardware it shouldn't be in the driver, it's a pure software thing which will also apply to any other similar hardware and should therefore be done in the core. > > > + pm_runtime_get_sync(pspim->dev); > > To repeat the feedback from last time do not open code runtime PM, use the > > core support. > Only set set the auto_runtime_pm of should be struct * spi_controller in probe function right ? Yes. > > > + list_for_each_entry(xfer, &m->transfers, transfer_list) { > > > + if (!first_xfer) > > > + first_xfer = xfer; > > > + total_len += xfer->len; > > To further repeat my prior feedback I can't see any reason why this driver > > doesn't just use transfer_one(). > The FIFO only 16bytes for one action. I need push tx_data and pull rx_data as soon as possible. > Use one message I can collect the data first and start transmitting > It is more efficient than transfer_one at real case. That doesn't mean it's a good idea to just duplicate the core code, that means that you should look into improving the performance of the core code so any optimisation benefits everyone and the driver doesn't end up with some combination of bugs, missing features and reduced performance in the open coded version. Having small FIFOs isn't at all unusual so it seems unlikely that there's any need for anything here to be device specific, and any benefits from copying all the data into a linear buffer have got to be application specific, indeed it'll clearly make things worse in some common cases. For example with something like flash where we have frequent use of large transfers for data payloads the data is already mostly in large buffers the overhead of copying those buffers is going to be very noticable compared to any saving, especially given that there's only two transfers. On the other end of things when something like regmap is already linearising small writes into single transfers then the copy is just pure overhead. There's definitely scope for improving things here, the main one being to pull advancing to the next transfer into spi_finalize_current_transfer() which would benefit DMA as well, that don't introduce these overheads and don't involve all this code duplication.
On Thu, Nov 11, 2021 at 08:32:39AM +0000, Lh Kuo 郭力豪 wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > #define SPI_CS_HIGH 0x04 /* chipselect active high? */ > Is it mean? > CASE1 : standby, CS high => start transfer CS become low => transfer end CS become high and standby > CASE2 : standby, CS low => start transfer CS become high => transfer end CS become low and standby > I think SPI_CS_HIGH means CASE2, But it is strange that more chipset work in CASE1 but drivers set SPI_CS_HIGH as defined. SPI_CS_HIGH is case 2. > 2. And in the CASE1 I should set > cs_gpios = <gpio 3 2 GPIO_ACTIVE_LOW>, > or > cs_gpios = <gpio 3 2 GPIO_ACTIVE_HIGH>, _ACTIVE_HIGH if _CS_HIGH is specified, though the binding will try to sort things out either way. > 3. If I did not set the max_transfer_size of spi_control > And use transfer_one set max_transfer_size and use_gpio_descriptors > Can it transmit data that exceeds FIFO max bytes (even exceed HW's one-time transfer) in one transmission activity? Yes, if you don't set a maximum transfer size the driver might get any transfer size. If you set a maximum transfer size then the driver will not see any transfers that exceed the maximum transfer size. > This is my concern, so I use Transfer_One_message I can't understand how that would follow on. If there's a limit on the size of an individual transfer then tell the framework about that limit, that's all that needs doing. Why would it be preferable to not tell the core about the limit and instead open code things? *Please* think about the lengthy explanation I provided in my last message about putting things that are not device specific in the framework not the driver. > Ex : Need to transmit 4000 bytes. > Then I set Ctlr->transfer_one and use_gpio_descriptors > ctlr->max_transfer_size = 255; > The CS of device is low active > When the transmission starts, I can see the signal gpio-CS changes from high to low > Ctlr->transfer_one will be triggered to execute 16 times, and transfer end gpio-CS changes from low to high. This is exactly what will happen if you do as has been repeatedly suggested. Set a maximum *transfer* (not message) size, let the core handle the chip select GPIO and implement transfer_one().
On Wed, Nov 17, 2021 at 09:11:08AM +0000, Lh Kuo 郭力豪 wrote: > The main function are as follows > > The sp7021_spi_mas_transfer_one is replace the transfer_one_message function. > > static int sp7021_spi_mas_transfer_one(struct spi_controller *ctlr, > struct spi_device *spi, struct spi_transfer *xfer) > { > struct sp7021_spi_ctlr *pspim = spi_master_get_devdata(ctlr); > u32 reg_temp = 0; > unsigned long timeout = msecs_to_jiffies(1000); I'm still not clear why this needs to be transfer_one_message() and not just transfer_one()? The whole thing with copying everything into a buffer is a bit confusing to me. > The probe function is as follows. > > static int sp7021_spi_controller_probe(struct platform_device *pdev) > { > int ret; > int mode; > struct spi_controller *ctlr; > struct sp7021_spi_ctlr *pspim; This looks fine.
On Fri, Nov 19, 2021 at 01:51:15AM +0000, Lh Kuo 郭力豪 wrote:
> The driver made a lot of changes. Which function do you want to check first, or can i make a new patch ? And we can review on this basis.
It will be easiest to send a new patch. The bits you included
here looked fine at first glance.