lkml.org 
[lkml]   [2019]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/3] spi: Add HiSilicon v3xx SPI NOR flash controller driver
From
Date
On 04/11/2019 19:24, Mark Brown wrote:
> On Tue, Nov 05, 2019 at 12:51:36AM +0800, John Garry wrote:
>

Hi Mark,

>> Only ACPI firmware is supported.
>
> There's no ACPI dependency though? If the driver only works with ACPI
> I'd expect to see one with an || COMPILE_TEST like the architecture
> dependency.

Yeah, you're right. So the driver can build for !ACPI and !COMPILE_TEST,
but there's no point really. I'll update.

>
>> @@ -0,0 +1,287 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * HiSilicon SPI NOR V3XX Flash Controller Driver for hi16xx chipsets
>> + *
>
> Please make the entire comment a C++ one for neatness.

ok

>
>> + * Copyright (c) 2019 HiSilicon Technologies Co., Ltd.
>> + * Author: John Garry <john.garry@huawei.com>
>> + */
>> +//#define DEBUG 1
>
> Please remove this.

ok

>
>> +#define GLOBAL_CFG (0x100)
>> +
>> +#define BUS_CFG1 (0x200)
>> +#define BUS_CFG2 (0x204)
>> +#define BUS_FLASH_SIZE (0x210)
>> +
>> +#define VERSION (0x1f8)
>
> These could use some namespacing, especially the last one - it seems
> quite likely there'll be some collisions at some point.

ok

>
>> +#define HISI_SFC_V3XX_WAIT_TIMEOUT_US 1000000
>> +#define HISI_SFC_V3XX_WAIT_POLL_INTERVAL_US 10
>
> Plus if we've got these long prefixes here it'd be good to be
> consistent.

sure

>
>> + if (IS_ALIGNED((uintptr_t)to, 4)) {
>> + int words = len / 4;
>> +
>> + __ioread32_copy(to, host->regbase + CMD_DATABUF(0), words);
>> +
>> + len -= words * 4;
>> + if (len) {
>> + u32 val;
>> +
>> + val = __raw_readl(host->regbase + CMD_DATABUF(words));
>> +
>> + to += words * 4;
>> + for (i = 0; i < len; i++, val >>= 8, to++)
>> + *to = (u8)val;
>> + }
>> + } else {
>> + for (i = 0; i < DIV_ROUND_UP(len, 4); i++) {
>> + u32 val = __raw_readl(host->regbase + CMD_DATABUF(i));
>> + int j;
>
> The more usual pattern for these would be to do some unaligned accesses
> for the start/end of the buffer to get to alignment and then transfer
> the rest as aligned data.
>

Yeah, I understand you, but for that I would need to generate multiple
transactions in the driver, and I wanted to keep 1x transaction per
spi_controller_mem_ops.exec_op call.

So maybe I can do some trickery in my adjust_op_size method to generate
these multiple transactions: a. any unaligned start data b. the
32b-aligned data b. unaligned end. I think that the HW should be able to
handle that.

Thanks,
John

\
 
 \ /
  Last update: 2019-11-05 11:59    [W:0.073 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site