[RFC 6/6] bus: Add support for Tegra NOR controller
Jon Hunter
jonathanh at nvidia.com
Fri Jul 22 02:38:56 PDT 2016
On 21/07/16 21:42, Mirza Krak wrote:
> 2016-07-21 12:15 GMT+02:00 Jon Hunter <jonathanh at nvidia.com>:
>>
>> On 19/07/16 14:36, Mirza Krak wrote:
>>> From: Mirza Krak <mirza.krak at gmail.com>
>>> +config TEGRA_NOR
>>> + tristate "Nvidia Tegra NOR flash bus driver a.k.a GMI/SNOR"
>>> + depends on ARCH_TEGRA_2x_SOC || ARCH_TEGRA_3x_SOC
>>> + depends on OF
>>> + help
>>> + Driver for NOR flash bus found on Tegra30/20 SOC`s.
>>
>> It is actually present on all Tegra's and so I would drop the 30/20.
>
> ACK.
>
>>> +++ b/drivers/bus/tegra-nor.c
>>> @@ -0,0 +1,118 @@
>>> +/*
>>> + * Driver for Nvidia NOR Flash bus a.k.a SNOR/GMI.
>>> + *
>>> + * Copyright (C) 2016 Host Mobility AB. All rights reserved.
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2. This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>> +#include <linux/io.h>
>>> +#include <linux/mfd/syscon.h>
>>
>> Is this needed?
>
> It is not. ACK.
>
>>
>>> +#include <linux/module.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/regmap.h>
>>
>> Or this?
>
> It is not. ACK.
>
>>
>>> +
>>> +#define TEGRA_NOR_TIMING_REG_COUNT 2
>>> +
>>> +#define TEGRA_NOR_CONFIG 0x00
>>> +#define TEGRA_NOR_STATUS 0x04
>>> +#define TEGRA_NOR_ADDR_PTR 0x08
>>> +#define TEGRA_NOR_AHB_ADDR_PTR 0x0c
>>> +#define TEGRA_NOR_TIMING0 0x10
>>> +#define TEGRA_NOR_TIMING1 0x14
>>> +#define TEGRA_NOR_MIO_CONFIG 0x18
>>> +#define TEGRA_NOR_MIO_TIMING 0x1c
>>> +#define TEGRA_NOR_DMA_CONFIG 0x20
>>> +#define TEGRA_NOR_CS_MUX_CONFIG 0x24
>>
>> Not all of these are used. It is good to define them and I wonder if we
>> should add support for MIO while are at it :-)
>
> We can come back to this once I have all SNOR stuff in order.
>
>>
>>> +
>>> +#define TEGRA_NOR_CONFIG_GO BIT(31)
>>> +
>>> +static const struct of_device_id nor_id_table[] = {
>>> + /* Tegra30 */
>>
>> I don't think this comment is needed.
>
> ACK.
>
>>
>>> + { .compatible = "nvidia,tegra30-nor", .data = NULL, },
>>
>> You don't need to set data to NULL.
>
> ACK.
>
>>
>>> + /* Tegra20 */
>>> + { .compatible = "nvidia,tegra20-nor", .data = NULL, },
>>
>> Same here.
>
> ACK
>
>>> +static int __init nor_probe(struct platform_device *pdev)
>>> +{
>>
>> I would drop the __init.
>
> ACK.
>
>>> +static struct platform_driver nor_driver = {
>>> + .driver = {
>>> + .name = "tegra-nor",
>>> + .of_match_table = nor_id_table,
>>> + },
>>> +};
>>
>> The driver should have a remove function given that we can build as a
>> module.
>
> At the moment I do not know what we would do in a remove function and
> hence me not adding one.
Should just be the inverse of the probe (although there is no inverse
for the parsing DT bit). If you don't wish to add a remove, that is
fine, but make the driver a 'bool' and not 'tristate' in the Kconfig so
it cannot be configured as a module.
>>
>>> +module_platform_driver_probe(nor_driver, nor_probe);
>>
>> I would use "tegra_nor" namespace for all the structs, functions, etc.
>> However, we may prefer to go with GMI and in which case tegra_gmi_probe,
>> etc.
>
> ACK. Who gets the last call on what we should call the driver? It
> seems that we both think GMI is a better name, do we need a third? :).
The patches would have to go via Thierry and so ultimately, Thierry.
However, I can't imagine he would object to GMI ;-)
Jon
--
nvpublic
More information about the linux-arm-kernel
mailing list