search for: slim_rproc

...y IPs in the STi chipsets such as fdma and demux. To avoid duplicating the elf loading code in each device driver a slim rproc driver has been created. This driver is designed to be used by other device drivers such as fdma, or demux whose IP is based around a slim core. The device driver can call slim_rproc_alloc() to allocate a slim rproc and slim_rproc_put() when finished. This driver takes care of ioremapping the slim registers (dmem, imem, slimcore, peripherals), whose offsets and sizes can change between IP's. It also obtains and enables any clocks used by the device. This approach avoids ha...

...as fdma and demux. To avoid duplicating > the elf loading code in each device driver a slim > rproc driver has been created. > > This driver is designed to be used by other device drivers > such as fdma, or demux whose IP is based around a slim core. > The device driver can call slim_rproc_alloc() to allocate > a slim rproc and slim_rproc_put() when finished. > > This driver takes care of ioremapping the slim > registers (dmem, imem, slimcore, peripherals), whose offsets > and sizes can change between IP's. It also obtains and enables > any clocks used by the d...

...as fdma and demux. To avoid duplicating > the elf loading code in each device driver a slim > rproc driver has been created. > > This driver is designed to be used by other device drivers > such as fdma, or demux whose IP is based around a slim core. > The device driver can call slim_rproc_alloc() to allocate > a slim rproc and slim_rproc_put() when finished. > > This driver takes care of ioremapping the slim > registers (dmem, imem, slimcore, peripherals), whose offsets > and sizes can change between IP's. It also obtains and enables > any clocks used by the d...

...uplicating > > the elf loading code in each device driver a slim > > rproc driver has been created. > > > > This driver is designed to be used by other device drivers > > such as fdma, or demux whose IP is based around a slim core. > > The device driver can call slim_rproc_alloc() to allocate > > a slim rproc and slim_rproc_put() when finished. > > > > This driver takes care of ioremapping the slim > > registers (dmem, imem, slimcore, peripherals), whose offsets > > and sizes can change between IP's. It also obtains and enables >...

...ments a new mechanism for firmware on late mounted root filesystems, we can migrate this driver over to use it at that point. v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects slim_rproc driver. The series has also been rebased on v4.8-rc3. regards, Peter. Changes since v7: - Rebase on v4.8-rc3 (Peter) - Double check that len is <= mem[i].size (Bjorn) - Remove if (!fw) checks (Bjorn) - Omit reference from fw_ops struct (Bjorn) - Call rproc_del() before rproc_put() (Bjorn...

...ments a new mechanism for firmware on late mounted root filesystems, we can migrate this driver over to use it at that point. v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects slim_rproc driver. The series has also been rebased on v4.8-rc3. regards, Peter. Changes since v7: - Rebase on v4.8-rc3 (Peter) - Double check that len is <= mem[i].size (Bjorn) - Remove if (!fw) checks (Bjorn) - Omit reference from fw_ops struct (Bjorn) - Call rproc_del() before rproc_put() (Bjorn...

...} > + > + ret = devm_request_irq(&pdev->dev, fdev->irq, st_fdma_irq_handler, 0, > + dev_name(&pdev->dev), fdev); > + if (ret) { > + dev_err(&pdev->dev, "Failed to request irq (%d)\n", ret); > + goto err; > + } > + > + fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name); > + if (!fdev->slim_rproc) { > + ret = PTR_ERR(fdev->slim_rproc); > + dev_err(&pdev->dev, "slim_rproc_alloc failed (%d)\n", ret); > + goto err; > + } > + > + /* Initialise list of FDMA channels */ > + I...

...} > + > + ret = devm_request_irq(&pdev->dev, fdev->irq, st_fdma_irq_handler, 0, > + dev_name(&pdev->dev), fdev); > + if (ret) { > + dev_err(&pdev->dev, "Failed to request irq (%d)\n", ret); > + goto err; > + } > + > + fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name); > + if (!fdev->slim_rproc) { > + ret = PTR_ERR(fdev->slim_rproc); > + dev_err(&pdev->dev, "slim_rproc_alloc failed (%d)\n", ret); > + goto err; > + } > + > + /* Initialise list of FDMA channels */ > + I...

...cmd = FDMA_CMD_START(fchan->vchan.chan.chan_id); + ch_cmd = fchan->fdesc->node[0].pdesc | FDMA_CH_CMD_STA_START; + + /* start the channel for the descriptor */ + fnode_write(fchan, nbytes, FDMA_CNTN_OFST); + fchan_write(fchan, ch_cmd, FDMA_CH_CMD_OFST); + writel(cmd, + fchan->fdev->slim_rproc->peri + FDMA_CMD_SET_OFST); + + dev_dbg(fchan->fdev->dev, "start chan:%d\n", fchan->vchan.chan.chan_id); +} + +static void st_fdma_ch_sta_update(struct st_fdma_chan *fchan, + unsigned long int_sta) +{ + unsigned long ch_sta, ch_err; + int ch_id = fchan->vchan.chan.chan...

...ng. All the drivers (outside of remoteproc), > >> that I've seen, depend on the core component, they don't select it. > > > > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and > > why it is like it is. > > > > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all > > the other drivers in the remoteproc subsystem which has exposed this recursive > > dependency issue. > > > > For this particular kconfig symbol a quick grep reveals more drivers in > > the kernel using 'select'...

...ng. All the drivers (outside of remoteproc), > >> that I've seen, depend on the core component, they don't select it. > > > > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and > > why it is like it is. > > > > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all > > the other drivers in the remoteproc subsystem which has exposed this recursive > > dependency issue. > > > > For this particular kconfig symbol a quick grep reveals more drivers in > > the kernel using 'select'...

...side of remoteproc), >> >> that I've seen, depend on the core component, they don't select it. >> > >> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and >> > why it is like it is. >> > >> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all >> > the other drivers in the remoteproc subsystem which has exposed this recursive >> > dependency issue. >> > >> > For this particular kconfig symbol a quick grep reveals more drivers in >> > the kernel us...

...side of remoteproc), >> >> that I've seen, depend on the core component, they don't select it. >> > >> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and >> > why it is like it is. >> > >> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all >> > the other drivers in the remoteproc subsystem which has exposed this recursive >> > dependency issue. >> > >> > For this particular kconfig symbol a quick grep reveals more drivers in >> > the kernel us...

...ng. All the drivers (outside of remoteproc), > >> that I've seen, depend on the core component, they don't select it. > > > > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and > > why it is like it is. > > > > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all > > the other drivers in the remoteproc subsystem which has exposed this recursive > > dependency issue. > > > > For this particular kconfig symbol a quick grep reveals more drivers in > > the kernel using 'select'...

...ng. All the drivers (outside of remoteproc), > >> that I've seen, depend on the core component, they don't select it. > > > > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and > > why it is like it is. > > > > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all > > the other drivers in the remoteproc subsystem which has exposed this recursive > > dependency issue. > > > > For this particular kconfig symbol a quick grep reveals more drivers in > > the kernel using 'select'...