Re: [PATCH] ASoC: fsl_esai: Fix divisor calculation failure at lower ratio
On 04/09/2018 01:57 AM, Nicolin Chen wrote:
> When the desired ratio is less than 256, the savesub (tolerance)
> in the calculation would become 0. This will then fail the loop-
> search immediately without reporting any errors.
>
> But if the ratio is smaller enough, there is no need to calculate
> the tolerance because PM divisor alone is enough to get the ratio.
>
> So a simple fix could be just to set PM directly instead of going
> into the loop-search.
>
> Reported-by: Marek Vasut <ma...@denx.de>
> Signed-off-by: Nicolin Chen <nicoleots...@gmail.com>
> Cc: Marek Vasut <ma...@denx.de>
On i.MX6Q with TI PCM1808
Tested-by: Marek Vasut <ma...@denx.de>
> ---
> sound/soc/fsl/fsl_esai.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index 40a7004..da8fd98 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -144,6 +144,13 @@ static int fsl_esai_divisor_cal(struct snd_soc_dai *dai,
> bool tx, u32 ratio,
>
> psr = ratio <= 256 * maxfp ? ESAI_xCCR_xPSR_BYPASS :
> ESAI_xCCR_xPSR_DIV8;
>
> + /* Do not loop-search if PM (1 ~ 256) alone can serve the ratio */
> + if (ratio <= 256) {
> + pm = ratio;
> + fp = 1;
> + goto out;
> + }
> +
> /* Set the max fluctuation -- 0.1% of the max devisor */
> savesub = (psr ? 1 : 8) * 256 * maxfp / 1000;
>
>
--
Best regards,
Marek Vasut
Re: [PATCH 00/22] mtd: nand: return error code of nand_scan(_ident, _tail) on error
On 11/04/2016 11:42 AM, Masahiro Yamada wrote: > > nand_scan(), nand_scan_ident(), nand_scan_tail() return > an appropriate negative value on error. > > Most of drivers return the value from them on error, > but some of them return the fixed error code -ENXIO > (and a few return -ENODEV). > > This series make those drivers return more precise error code. > Reviewed-by: Marek Vasut <marek.va...@gmail.com> Nice cleanup, thanks! -- Best regards, Marek Vasut
Re: [PATCH] crypto/nx: disable NX on little endian builds
On Saturday, June 07, 2014 at 03:33:34 AM, Anton Blanchard wrote: The NX driver has endian issues so disable it for now. Signed-off-by: Anton Blanchard an...@samba.org What kind of issues ? Are they hard to fix ? Best regards, Marek Vasut ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
On Friday, April 18, 2014 at 08:30:54 AM, Brian Norris wrote: Hi, On Thu, Apr 17, 2014 at 12:53:03PM +0200, Thierry Reding wrote: On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote: We are introducing a new SPI-NOR library/framework for MTD, to support various types of SPI-NOR flash controllers which require (or benefit from) intimate knowledge of the flash interface, rather than just the relatively dumb SPI interface. This library borrows much of the m25p80 driver for its abstraction and moves this code into a spi-nor module. If this is a common library, then the more common approach to solve this would be to have each driver that uses it to select MTD_SPI_NOR rather than depend on it. That way you can drop this whole series to update the default configurations. But does MTD_SPI_NOR (and drivers/mtd/spi-nor/) qualify as a library or as a subsystem? I thought the latter were typically expected to be user-selectable options, not automatically-selected. I agree the subsystem is user-selectable while the library is to be 'select'ed . I would say that, except for its age, MTD_SPI_NOR is very similar in to MTD_NAND (driver/mtd/nand/), which I'd consider a kind of subsystem, and which users must select before they are asked about drivers which fall under its category. Perhaps my usage of the word library in the description was a mistake, as I don't exactly consider it like a library in the sense of many other selected libraries. It did look like a library to me at first, but it's rather a subsystem that contains a small library in it. Thus, I retract my previous comment about using 'select' and add : Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
On Thursday, April 17, 2014 at 09:21:44 AM, Brian Norris wrote: Hi all, We are introducing a new SPI-NOR library/framework for MTD, to support various types of SPI-NOR flash controllers which require (or benefit from) intimate knowledge of the flash interface, rather than just the relatively dumb SPI interface. This library borrows much of the m25p80 driver for its abstraction and moves this code into a spi-nor module. This means CONFIG_M25P80 now has a dependency on CONFIG_MTD_SPI_NOR, which should be added to the defconfigs. I'm not sure what is the best process for doing this. Should each $ARCH maintainer just take their respective patch, even if the MTD_SPI_NOR Kconfig symbol is not defined for them yet? Or should maintainers plan on merging the relevant SPI-NOR code into their trees during the development cycle? Or some third option? Shouldn't the M25P80 driver just select the SPI NOR framework? Then you won't need the adjustment to defconfigs at all I think. Best regards, Marek Vasut ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c: Remove unneeded xxx_set_drvdata(..., NULL) calls
Dear Doug Anderson, There is simply no reason to be manually setting the private driver data to NULL in the remove/fail to probe cases. This is just extra cruft code that can be removed. A few notes: * Nothing relies on drvdata being set to NULL. * The __device_release_driver() function eventually calls dev_set_drvdata(dev, NULL) anyway, so there's no need to do it twice. * I verified that there were no cases where xxx_get_drvdata() was being called in these drivers and checking for / relying on the NULL return value. This could be cleaned up kernel-wide but for now just take the baby step and remove from the i2c subsystem. Reported-by: Wolfram Sang w...@the-dreams.de Reported-by: Stephen Warren swar...@wwwdotorg.org Signed-off-by: Doug Anderson diand...@chromium.org For drivers/i2c/busses/i2c-mxs.c| 2 -- [...] diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c index 22d8ad3..120f246 100644 --- a/drivers/i2c/busses/i2c-mxs.c +++ b/drivers/i2c/busses/i2c-mxs.c @@ -697,8 +697,6 @@ static int mxs_i2c_remove(struct platform_device *pdev) writel(MXS_I2C_CTRL0_SFTRST, i2c-regs + MXS_I2C_CTRL0_SET); - platform_set_drvdata(pdev, NULL); - return 0; } [...] Add my: Reviewed-by: Marek Vasut ma...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driverkernel 2.6.33resubmission
Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a): This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. Signed-off-by: Rupjyoti Sarmah rsar...@appliedmicro.com Signed-off-by: Mark Miesfeld mmiesf...@appliedmicro.com Signed-off-by: Prodyut Hazarika phazar...@appliedmicro.com --SNIP-- + dev_err(ap-dev, %s: Command not pending cmd_issued=%d + (tag=%d) DMA NOT started\n, __func__, + hsdevp-cmd_issued[tag], tag); Just a nitpick, but don't break strings if possible. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
