Re: [PATCH v2 30/30] media: atmel: atmel-isc: add microchip-xisc driver
On 4/12/21 4:41 PM, Jacopo Mondi wrote:
> Hi Eugene,
>
> On Mon, Apr 12, 2021 at 12:37:41PM +, eugen.hris...@microchip.com wrote:
>>> +static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
>>> +{
>>> + struct device_node *np = dev->of_node;
>>> + struct device_node *epn = NULL;
>>> + struct isc_subdev_entity *subdev_entity;
>>> + unsigned int flags;
>>> + int ret;
>>> + bool mipi_mode;
>>> +
>>> + INIT_LIST_HEAD(>subdev_entities);
>>> +
>>> + mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
>>> +
>>> + while (1) {
>>> + struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
>>> +
>>> + epn = of_graph_get_next_endpoint(np, epn);
>>> + if (!epn)
>>> + return 0;
>>> +
>>> + ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
>>> +_epn);
>>> + if (ret) {
>>> + ret = -EINVAL;
>>> + dev_err(dev, "Could not parse the endpoint\n");
>>> + break;
>>> + }
>>> +
>>> + subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
>>> +GFP_KERNEL);
>>> + if (!subdev_entity) {
>>> + ret = -ENOMEM;
>>> + break;
>>> + }
>>> + subdev_entity->epn = epn;
>>> +
>>> + flags = v4l2_epn.bus.parallel.flags;
>>> +
>>> + if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
>>> + subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
>>> +
>>> + if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
>>> + subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
>>> +
>>> + if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
>>> + subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
>>> +
>>> + if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
>>> + subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
>>> + ISC_PFE_CFG0_CCIR656;
>>
>> Hi Jacopo,
>>
>> If I use the bus-type property for the 'port' , do I actually have to
>> change something here ?
>
> You can set bus_type to the desired type, if it doesn't match the
> 'bus-type' property you will have an immediate error and a more strict
> check on the properties.
>
> You would likely:
>
> v4l2_epn.bus_type = V4L2_MBUS_PARALLEL;
> ret = v4l2_fwnode_endpoint_parse()
> if (!ret) {
> /* It's parallel */
> } else {
> v4l2_epn.bus_type = V4L2_MBUS_BT656;
> ret = v4l2_fwnode_endpoint_parse()
> if (ret) {
> /* Unsupported bus type: error out. */
> }
>
> /* It's BT656 */
> }
if the v4l2_fwnode_endpoint_parse will already fill in the
v4l2_epn.bus_type based on what is found in the 'bus-type' , why do I
need to do this assumption-fail-assumption-fail scenario ?
Can't I simply check the value of v4l2_epn.bus_type , as I am doing it
already ?
>
> Not the greatest API, but it's more robust.
>
>> the v4l2_epn.bus_type won't be set automatically ? by the endpoint
>> parser I mean.
>
> Yes, that's what auto-discovery is, the endpoint parser tries to
> deduce the bus type from the properties that are there specified. It
> works, but leaves quite some ambiguity between ie PARALLEL and BT656
> as some polarities might not be necessarily specified even for
> PARALLEL bus types.
>
> As I've said, there's still plenty of code that relies on
> auto-discovery so I don't think this is blocking, also because making
> bus-type mandatory on existing DTS is quite painful. Since this is a
> new DTS you can consider this solution if you want to.
>
> Thanks
> j
>
>>
>> Thanks,
>> Eugen
>>
>>> +
>>> + if (mipi_mode)
>>> + subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
>>> +
>>> + list_add_tail(_entity->list, >subdev_entities);
>>> + }
>>> + of_node_put(epn);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int microchip_xisc_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *dev = >dev;
>>> + struct isc_device *isc;
>>> + struct resource *res;
>>> + void __iomem *io_base;
>>> + struct isc_subdev_entity *subdev_entity;
>>> + int irq;
>>> + int ret;
>>> + u32 ver;
>>> +
>>> + isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
>>> + if (!isc)
>>> + return -ENOMEM;
>>> +
>>> + platform_set_drvdata(pdev, isc);
>>> + isc->dev = dev;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + io_base = devm_ioremap_resource(dev, res);
>>> + if (IS_ERR(io_base))
>>> + return PTR_ERR(io_base);
>>> +
>>> + isc->regmap = devm_regmap_init_mmio(dev, io_base, _regmap_config);
>>> + if (IS_ERR(isc->regmap)) {
>>> + ret = PTR_ERR(isc->regmap);
>>> + dev_err(dev, "failed to
Re: [PATCH v2 30/30] media: atmel: atmel-isc: add microchip-xisc driver
On 4/5/21 6:51 PM, Eugen Hristev wrote: > Add driver for the extended variant of the isc, the microchip XISC > present on sama7g5 product. > > Signed-off-by: Eugen Hristev > --- > Changes in v2: > - adapted to new fwnode subdev style API, as in kernel 5.12. > my old code was based on 5.10 style API. > > drivers/media/platform/Makefile | 1 + > drivers/media/platform/atmel/Kconfig | 11 + > drivers/media/platform/atmel/Makefile | 2 + > drivers/media/platform/atmel/atmel-isc-base.c | 2 +- > drivers/media/platform/atmel/atmel-isc-regs.h | 26 + > .../media/platform/atmel/atmel-sama7g5-isc.c | 643 ++ > 6 files changed, 684 insertions(+), 1 deletion(-) > create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c > > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index eedc14aafb32..73ce083c2fc6 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)+= rcar-vin/ > > obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel/ > obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel/ > +obj-$(CONFIG_VIDEO_ATMEL_XISC) += atmel/ > > obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32/ > > diff --git a/drivers/media/platform/atmel/Kconfig > b/drivers/media/platform/atmel/Kconfig > index 1850fe7f9360..99b51213f871 100644 > --- a/drivers/media/platform/atmel/Kconfig > +++ b/drivers/media/platform/atmel/Kconfig > @@ -12,6 +12,17 @@ config VIDEO_ATMEL_ISC > This module makes the ATMEL Image Sensor Controller available > as a v4l2 device. > > +config VIDEO_ATMEL_XISC > + tristate "ATMEL eXtended Image Sensor Controller (XISC) support" > + depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API > + depends on ARCH_AT91 || COMPILE_TEST > + select VIDEOBUF2_DMA_CONTIG > + select REGMAP_MMIO > + select V4L2_FWNODE > + help > +This module makes the ATMEL eXtended Image Sensor Controller > +available as a v4l2 device. > + > config VIDEO_ATMEL_ISI > tristate "ATMEL Image Sensor Interface (ISI) support" > depends on VIDEO_V4L2 && OF > diff --git a/drivers/media/platform/atmel/Makefile > b/drivers/media/platform/atmel/Makefile > index 2dba38994a70..c5c01556c653 100644 > --- a/drivers/media/platform/atmel/Makefile > +++ b/drivers/media/platform/atmel/Makefile > @@ -1,5 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0-only > atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o > +atmel-xisc-objs = atmel-sama7g5-isc.o atmel-isc-base.o > > obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o > obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o > +obj-$(CONFIG_VIDEO_ATMEL_XISC) += atmel-xisc.o > diff --git a/drivers/media/platform/atmel/atmel-isc-base.c > b/drivers/media/platform/atmel/atmel-isc-base.c > index f30493a1dccd..d6409406ce2f 100644 > --- a/drivers/media/platform/atmel/atmel-isc-base.c > +++ b/drivers/media/platform/atmel/atmel-isc-base.c > @@ -592,7 +592,7 @@ static int isc_configure(struct isc_device *isc) > mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW | > ISC_PFE_CFG0_VPOL_LOW | ISC_PFE_CFG0_PPOL_LOW | > ISC_PFE_CFG0_MODE_MASK | ISC_PFE_CFG0_CCIR_CRC | > -ISC_PFE_CFG0_CCIR656; > +ISC_PFE_CFG0_CCIR656 | ISC_PFE_CFG0_MIPI; > > regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0); > > diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h > b/drivers/media/platform/atmel/atmel-isc-regs.h > index 5f99bf7717c1..d06b72228d4f 100644 > --- a/drivers/media/platform/atmel/atmel-isc-regs.h > +++ b/drivers/media/platform/atmel/atmel-isc-regs.h > @@ -26,6 +26,7 @@ > #define ISC_PFE_CFG0_PPOL_LOW BIT(2) > #define ISC_PFE_CFG0_CCIR656BIT(9) > #define ISC_PFE_CFG0_CCIR_CRC BIT(10) > +#define ISC_PFE_CFG0_MIPIBIT(14) > > #define ISC_PFE_CFG0_MODE_PROGRESSIVE (0x0 << 4) > #define ISC_PFE_CFG0_MODE_MASK GENMASK(6, 4) > @@ -184,6 +185,8 @@ > /* ISC Gamma Correction Control Register */ > #define ISC_GAM_CTRL0x0094 > > +#define ISC_GAM_CTRL_BIPART BIT(4) > + > /* ISC_Gamma Correction Blue Entry Register */ > #define ISC_GAM_BENTRY 0x0098 > > @@ -222,6 +225,8 @@ > > /* Offset for CSC register specific to sama5d2 product */ > #define ISC_SAMA5D2_CSC_OFFSET 0 > +/* Offset for CSC register specific to sama7g5 product */ > +#define ISC_SAMA7G5_CSC_OFFSET 0x11c > > /* Color Space Conversion Control Register */ > #define ISC_CSC_CTRL0x0398 > @@ -246,6 +251,8 @@ > > /* Offset for CBC register specific to sama5d2 product */ > #define ISC_SAMA5D2_CBC_OFFSET 0 > +/* Offset for CBC register specific to sama7g5 product */ > +#define ISC_SAMA7G5_CBC_OFFSET 0x11c > > /* Contrast And Brightness Control Register */ > #define ISC_CBC_CTRL
Re: [PATCH v2 28/30] dt-bindings: media: atmel: add microchip-xisc binding
On 4/12/21 12:57 PM, Jacopo Mondi wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Eugene,
>
> On Mon, Apr 05, 2021 at 06:51:03PM +0300, Eugen Hristev wrote:
>> Add bindings for the microchip xisc, a driver based on atmel-isc.
>> It shares common code with atmel-isc, but the xisc is the next generation
>> ISC which is present on sama7g5 product.
>> It has an enhanced pipeline, additional modules, formats, and it supports
>> not only parallel sensors, but also serial sensors, by connecting to a demux
>> endpoint present on sama7g5.
>> One of the key points for creating a new binding is the clocking scheme, as
>> atmel-isc requires 3 mandatory clocks, the microchip-xisc requires a single
>> input clock.
>>
>> Signed-off-by: Eugen Hristev
>> ---
>>
>> Hello Rob, all,
>>
>> I did not convert this yet to yaml because I would like first your feedback
>> if the binding is good.
>> If it's fine I will convert both this new binding and the old atmel-isc
>> to yaml.
>>
>> Thanks for your feedback,
>> Eugen
>>
>> .../bindings/media/microchip-xisc.txt | 64 +++
>> 1 file changed, 64 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/media/microchip-xisc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/microchip-xisc.txt
>> b/Documentation/devicetree/bindings/media/microchip-xisc.txt
>> new file mode 100644
>> index ..080a357ed84d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/microchip-xisc.txt
>> @@ -0,0 +1,64 @@
>> +Microchip eXtended Image Sensor Controller (XISC)
>> +--
>> +
>> +Required properties for XISC:
>> +- compatible
>> + Must be "microchip,sama7g5-xisc".
>> +- reg
>> + Physical base address and length of the registers set for the device.
>> +- interrupts
>> + Should contain IRQ line for the XISC.
>> +- clocks
>> + List of clock specifiers, corresponding to entries in
>> + the clock-names property;
>> + Please refer to clock-bindings.txt.
>> +- clock-names
>> + Required elements: "hclock".
>> + This is the clock that clocks the sensor controller, and is usually
>> + fed from the clock tree. It is used for the internal controller logic.
>> +- #clock-cells
>> + Should be 0.
>> +- clock-output-names
>> + Should be "isc-mck".
>> +- pinctrl-names, pinctrl-0
>> + Please refer to pinctrl-bindings.txt.
>> +
>> +Optional properties for XISC:
>> +- microchip,mipi-mode;
>> + As the XISC is usually connected to a demux/bridge, the XISC receives
>> + the same type of input, however, it should be aware of the type of
>> + signals received. The mipi-mode enables different internal handling
>> + of the data and clock lines.
>
> What does 'mipi-mode' do to a component that has an parallel receiver ?
Actually, this indeed has a parallel receiver, but it's only inside the
SoC. The other end of the parallel connection is a demuxer/bridge. This
demuxer will take the input from either a real parallel sensor or a CSI2
stream.
Even if the pixels are then converted into a parallel stream, it looks
like the pixel data has a bit of different constrains in term of hold
and setup time, and other electrical characteristics inside the SoC.
The XISC hardware designer decided to leave a bit in the user interface
called 'mipi-mode' , and by setting this, the capture interface of the
XISC is better adapted to a demuxed stream from a CSI2, rather than
adapted to a stream coming from a parallel sensor directly.
I am not sure I explained it right, but this is what I understand, when
I asked the hardware design about it.
So we have to manually set this bit if we have the demuxer deserializing
the CSI2 pixels or they are connected to a parallel sensor.
The XISC has no way of telling which is the correct setup, and from the
demuxer perspective, things are the same.
The endpoint connection between the xisc and the demuxer looks to be the
same, looking as if there is a parallel connection.
To know more, the XISC would be needing to look further down the
pipeline, and this is something which I could not force it to do.
>
>> +
>> +XISC supports a single port node with internal parallel bus.
>> +It should contain one 'port' child node with child 'endpoint' node.
>> +Please refer to the bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +This endpoint has to be connected to a bridge that acts as a demux from
>> either
>> +a serial interface or acts as a simple direct bridge to a parallel sensor.
>> +
>> +Example:
>> +xisc: xisc@e1408000 {
>> + compatible = "microchip,sama7g5-isc";
>> + reg = <0xe1408000 0x2000>;
>> + interrupts = ;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + clocks = < PMC_TYPE_PERIPHERAL 56>;
>> + clock-names = "hclock";
>> + #clock-cells = <0>;
>> +
Re: [PATCH v2 04/30] media: atmel: atmel-isc: specialize max width and max height
On 4/12/21 12:53 PM, Jacopo Mondi wrote:
> Ups,
>
> On Mon, Apr 12, 2021 at 11:43:12AM +0200, Jacopo Mondi wrote:
>> Hi Eugene,
>>
>> On Mon, Apr 05, 2021 at 06:50:39PM +0300, Eugen Hristev wrote:
>>> Move the max width and max height constants to the product specific driver
>>> and have them in the device struct.
>>>
>>> Signed-off-by: Eugen Hristev
>>> ---
>>> drivers/media/platform/atmel/atmel-isc-base.c | 28 +--
>>> drivers/media/platform/atmel/atmel-isc.h | 9 --
>>> .../media/platform/atmel/atmel-sama5d2-isc.c | 7 +++--
>>> 3 files changed, 25 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c
>>> b/drivers/media/platform/atmel/atmel-isc-base.c
>>> index 45fc8dbb7943..350076dd029a 100644
>>> --- a/drivers/media/platform/atmel/atmel-isc-base.c
>>> +++ b/drivers/media/platform/atmel/atmel-isc-base.c
>>> @@ -1204,8 +1204,8 @@ static void isc_try_fse(struct isc_device *isc,
>>> * just use the maximum ISC can receive.
>>> */
>>> if (ret) {
>>> - pad_cfg->try_crop.width = ISC_MAX_SUPPORT_WIDTH;
>>> - pad_cfg->try_crop.height = ISC_MAX_SUPPORT_HEIGHT;
>>> + pad_cfg->try_crop.width = isc->max_width;
>>> + pad_cfg->try_crop.height = isc->max_height;
>>> } else {
>>> pad_cfg->try_crop.width = fse.max_width;
>>> pad_cfg->try_crop.height = fse.max_height;
>>> @@ -1282,10 +1282,10 @@ static int isc_try_fmt(struct isc_device *isc,
>>> struct v4l2_format *f,
>>> isc->try_config.sd_format = sd_fmt;
>>>
>>> /* Limit to Atmel ISC hardware capabilities */
>>> - if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
>>> - pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
>>> - if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
>>> - pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
>>> + if (pixfmt->width > isc->max_width)
>>> + pixfmt->width = isc->max_width;
>>> + if (pixfmt->height > isc->max_height)
>>> + pixfmt->height = isc->max_height;
>>>
>>> /*
>>> * The mbus format is the one the subdev outputs.
>>> @@ -1327,10 +1327,10 @@ static int isc_try_fmt(struct isc_device *isc,
>>> struct v4l2_format *f,
>>> v4l2_fill_pix_format(pixfmt, );
>>>
>>> /* Limit to Atmel ISC hardware capabilities */
>>> - if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
>>> - pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
>>> - if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
>>> - pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
>>> + if (pixfmt->width > isc->max_width)
>>> + pixfmt->width = isc->max_width;
>>> + if (pixfmt->height > isc->max_height)
>>> + pixfmt->height = isc->max_height;
>>
>> What happens if the sensor sends a frame larger that the ISC max
>> supported sizes ?
>>
>
> I meant to ask this question on the previous patch :/
Hi Jacopo,
The ISC has a feature in the PFE module (parallel front end), the first
pixel capturing module, which will automatically crop the frame at the
maximum size (or configured frame size).
here is the commit that implements this safety mechanism :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=253ccf34232ae3b47497e5e55aef3ac48821425c
Eugen
>
>>>
>>> pixfmt->field = V4L2_FIELD_NONE;
>>> pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
>>> @@ -1368,10 +1368,10 @@ static int isc_set_fmt(struct isc_device *isc,
>>> struct v4l2_format *f)
>>> return ret;
>>>
>>> /* Limit to Atmel ISC hardware capabilities */
>>> - if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
>>> - pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
>>> - if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
>>> - pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
>>> + if (f->fmt.pix.width > isc->max_width)
>>> + f->fmt.pix.width = isc->max_width;
>>> + if (f->fmt.pix.height > isc->max_height)
>>> + f->fmt.pix.height = isc->max_height;
>>>
>>> isc->fmt = *f;
>>>
>>> diff --git a/drivers/media/platform/atmel/atmel-isc.h
>>> b/drivers/media/platform/atmel/atmel-isc.h
>>> index 8d81d9967ad2..6becc6c3aaf0 100644
>>> --- a/drivers/media/platform/atmel/atmel-isc.h
>>> +++ b/drivers/media/platform/atmel/atmel-isc.h
>>> @@ -10,9 +10,6 @@
>>>*/
>>> #ifndef _ATMEL_ISC_H_
>>>
>>> -#define ISC_MAX_SUPPORT_WIDTH 2592
>>> -#define ISC_MAX_SUPPORT_HEIGHT 1944
>>> -
>>> #define ISC_CLK_MAX_DIV255
>>>
>>> enum isc_clk_id {
>>> @@ -191,6 +188,9 @@ struct isc_ctrls {
>>>* @gamma_table: pointer to the table with gamma values, has
>>>* gamma_max sets of GAMMA_ENTRIES entries each
>>>* @gamma_max: maximum number of sets of inside the
>>> gamma_table
>>> + *
>>> + * @max_width: maximum frame width, dependent on the internal
>>> RAM
>>> + * @max_height:maximum frame height, dependent on the internal
>>> RAM
>>>*/
>>>
Re: [PATCH 3/3] ARM: at91: Kconfig: select PLL, generic clock and utmi support
On 4/7/21 8:13 PM, Alexandre Belloni wrote: > Hi, > > On 07/04/2021 20:00:53+0300, Eugen Hristev wrote: >> From: Claudiu Beznea >> >> Select PLL, generic clock and UTMI support for SAMA7G5. >> >> Signed-off-by: Claudiu Beznea >> Signed-off-by: Eugen Hristev >> --- >> arch/arm/mach-at91/Kconfig | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig >> index 5eb2a9206f42..f52b46bccd85 100644 >> --- a/arch/arm/mach-at91/Kconfig >> +++ b/arch/arm/mach-at91/Kconfig >> @@ -60,6 +60,9 @@ config SOC_SAMA5D4 >> config SOC_SAMA7G5 >>bool "SAMA7G5 family" >>depends on ARCH_MULTI_V7 >> + select HAVE_AT91_GENERATED_CLK >> + select HAVE_AT91_SAM9X60_PLL >> + select HAVE_AT91_UTMI > > Shouldn't that be squashed in 1/3? I kept the original contributions of each author. I can squash it into a single patch if it's cleaner. Eugen > >>select SOC_SAMA7 >>help >> Select this if you are using one of Microchip's SAMA7G5 family SoC. >> -- >> 2.25.1 >> > > -- > Alexandre Belloni, co-owner and COO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com >
Re: [PATCH 2/4] iio: adc: at91-sama5d2: initialize hardware after clock is started
On 06.03.2021 19:20, Jonathan Cameron wrote: > On Mon, 1 Mar 2021 16:32:54 +0200 > Eugen Hristev wrote: > >> The hw_init hardware init call must happen after the clock is prepared and >> enabled. Otherwise, writing to the registers might lead to a block or >> external abort. > > Fix for existing parts or something only needed for the new devices? > If it's a fix we should be looking to back port it so please > provide me with a fixes tag. > > If it's a fix but not super urgent then let me know and we can > take it with the rest of this series (and hence keep things simple) Hi Jonathan, It's not super urgent. Actually this issue could potentially impact other parts, but it was never hit, as the clocking of the ADC block in older products is done differently and the bridge connected to the block does not halt if requests are sent to an unclocked ADC. Most likely they are buffered and served once clock ticks. For the sama7g5, the ADC is in an asynchronous part of the architecture that is clocked by a generic clock that must be on, otherwise the full AXI4 will stall because no reply is coming as the ADC is not clocked. I do not fully grasp it, but this is my understanding. Anyway it makes sense for all products to not read/write registers in the block if the clock is not started yet. Eugen > > Thanks, > > Jonathan > >> >> Signed-off-by: Eugen Hristev >> --- >> drivers/iio/adc/at91-sama5d2_adc.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c >> b/drivers/iio/adc/at91-sama5d2_adc.c >> index a7826f097b95..63325f037f09 100644 >> --- a/drivers/iio/adc/at91-sama5d2_adc.c >> +++ b/drivers/iio/adc/at91-sama5d2_adc.c >> @@ -1832,12 +1832,12 @@ static int at91_adc_probe(struct platform_device >> *pdev) >>goto vref_disable; >>} >> >> - at91_adc_hw_init(indio_dev); >> - >>ret = clk_prepare_enable(st->per_clk); >>if (ret) >>goto vref_disable; >> >> + at91_adc_hw_init(indio_dev); >> + >>platform_set_drvdata(pdev, indio_dev); >> >>ret = at91_adc_buffer_and_trigger_init(>dev, indio_dev); >
Re: [PATCH 4/4] iio: adc: at91-sama5d2: add support for sama7g5 device
On 06.03.2021 19:30, Jonathan Cameron wrote:
> On Mon, 1 Mar 2021 16:32:56 +0200
> Eugen Hristev wrote:
>
>> Add support to sama7g5 ADC which is similar with sama5d2/sam9x60 device.
>> Differences are highlighted by compatible.
>> Main differences include 16 channels instead of 12 and missing
>> resistive touchscreen.
>>
>> Signed-off-by: Eugen Hristev
>
> Hi Eugen,
>
> What tends to end up cleaner than the many scattered places you have
> had to bolt in part support here, is to use a per device type constant
> structure. That structure can contain register addresses where that
> is all the differs between parts, and callbacks for more complex cases.
>
> Along the lines of
>
> static const struct sam5d2_chip_info sam5d2_inf {
> .eoc_register = 0x33,
> .max_chan_idx = bob,
> .ccr = bob_function,
> ...
> };
>
> Then you can just put a pointer to this in the match_data and look that
> up in probe
Hi Jonathan,
Could you have a look a little at this driver though:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/watchdog/sama5d4_wdt.c
The specific support for 'sam9x60' was added by me, and the driver does
not look so bad after all, having if/else clauses nearly everywhere, and
getting that 'sam9x60_supported' bit from the compatible string comparison.
That's the reason why I tried to have this ADC driver in a similar fashion.
I like your approach as well, I guess it's just a matter of preference.
I will start to change things to implement it as you suggested if you
don't say otherwise.
Thanks for reviewing,
Eugen
>
>> ---
>> drivers/iio/adc/at91-sama5d2_adc.c | 287 +++--
>> 1 file changed, 234 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c
>> b/drivers/iio/adc/at91-sama5d2_adc.c
>> index 066d0ad644ca..d61fa32ef294 100644
>> --- a/drivers/iio/adc/at91-sama5d2_adc.c
>> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
>> @@ -1,9 +1,11 @@
>> // SPDX-License-Identifier: GPL-2.0-only
>> /*
>> - * Atmel ADC driver for SAMA5D2 devices and compatible.
>> + * Microchip ADC driver for SAMA5D2/SAMA7G5 devices and compatible.
>>*
>>* Copyright (C) 2015 Atmel,
>> - * 2015 Ludovic Desroches
>> + * 2015 Ludovic Desroches ,
>> + *2021 Microchip Technology, Inc.,
>> + *2021 Eugen Hristev
>>*/
>>
>> #include
>> @@ -117,14 +119,26 @@
>> #define AT91_SAMA5D2_ISR 0x30
>> /* Interrupt Status Register - Pen touching sense status */
>> #define AT91_SAMA5D2_ISR_PENS BIT(31)
>> +
>> +/* End of Conversion Interrupt Enable Register */
>> +#define AT91_SAMA7G5_EOC_IER 0x34
>> +/* End of Conversion Interrupt Disable Register */
>> +#define AT91_SAMA7G5_EOC_IDR 0x38
>> +/* End of Conversion Interrupt Mask Register */
>> +#define AT91_SAMA7G5_EOC_IMR 0x3c
>> +/* End of Conversion Interrupt Status Register */
>> +#define AT91_SAMA7G5_EOC_ISR 0x40
>> +
>> /* Last Channel Trigger Mode Register */
>> #define AT91_SAMA5D2_LCTMR 0x34
>> /* Last Channel Compare Window Register */
>> #define AT91_SAMA5D2_LCCWR 0x38
>> /* Overrun Status Register */
>> #define AT91_SAMA5D2_OVER0x3c
>> +#define AT91_SAMA7G5_OVER0x4c
>> /* Extended Mode Register */
>> #define AT91_SAMA5D2_EMR 0x40
>> +#define AT91_SAMA7G5_EMR 0x50
>> /* Extended Mode Register - Oversampling rate */
>> #define AT91_SAMA5D2_EMR_OSR(V) ((V) << 16)
>> #define AT91_SAMA5D2_EMR_OSR_MASKGENMASK(17, 16)
>> @@ -142,6 +156,9 @@
>> /* Channel Offset Register */
>> #define AT91_SAMA5D2_COR 0x4c
>> #define AT91_SAMA5D2_COR_DIFF_OFFSET 16
>> +/* Channel Configuration Register */
>> +#define AT91_SAMA7G5_CCR 0x5c
>> +#define AT91_SAMA7G5_COR_DIFF_OFFSET 0
>>
>> /* Analog Control Register */
>> #define AT91_SAMA5D2_ACR 0x94
>> @@ -185,6 +202,7 @@
>> #define AT91_SAMA5D2_PRESSR 0xbc
>> /* Trigger Register */
>> #define AT91_SAMA5D2_TRGR0xc0
>> +#define AT91_SAMA7G5_TRGR0x100
>> /* Mask for TRGMOD field of TRGR register */
>> #define AT91_SAMA5D2_TRGR_TRGMOD_MASK GENMASK(2, 0)
>> /* No trigger, only software trigger can start conversions */
>> @@ -214,19 +232,26 @@
>> #define AT91_SAMA5D2_WPSR0xe8
>> /* Version Register */
>> #define AT91_SAMA5D2_VERSION 0xfc
>> +#define AT91_SAMA7G5_VERSION 0x130
>>
>> #define AT91_SAMA5D2_HW_TRIG_CNT 3
>> #define AT91_SAMA5D2_SINGLE_CHAN_CNT 12
>> +#define AT91_SAMA7G5_SINGLE_CHAN_CNT 16
>> #define AT91_SAMA5D2_DIFF_CHAN_CNT 6
>> +#define AT91_SAMA7G5_DIFF_CHAN_CNT 8
>>
>> #define AT91_SAMA5D2_TIMESTAMP_CHAN_IDX (AT91_SAMA5D2_SINGLE_CHAN_CNT + \
>> AT91_SAMA5D2_DIFF_CHAN_CNT + 1)
>>
>> +#define AT91_SAMA7G5_TIMESTAMP_CHAN_IDX (AT91_SAMA7G5_SINGLE_CHAN_CNT + \
>> + AT91_SAMA7G5_DIFF_CHAN_CNT + 1)
>> +
>> #define
Re: [PATCH] clk: at91: Fix the declaration of the clocks
On 03.02.2021 20:15, Saravana Kannan wrote: > On Wed, Feb 3, 2021 at 7:43 AM Tudor Ambarus > wrote: >> >> These are all "early clocks" that require initialization just at >> of_clk_init() time. Use CLK_OF_DECLARE() to declare them. >> >> This also fixes a problem that was spotted when fw_devlink was >> set to 'on' by default: the boards failed to boot. The reason is >> that CLK_OF_DECLARE_DRIVER() clears the OF_POPULATED and causes >> the consumers of the clock to be postponed by fw_devlink until >> the second initialization routine of the clock has been completed. >> One of the consumers of the clock is the timer, which is used as a >> clocksource, and needs the clock initialized early. Postponing the >> timers caused the fail at boot. >> >> Signed-off-by: Tudor Ambarus > > Thanks Tudor! > Acked-by: Saravana Kannan > > -Saravana > >> --- >> Tested on sama5d2_xplained. >> For sama5d3_xplained, sama5d4_xplained, Tested-by: Eugen Hristev
Re: [PATCH v5 2/3] media: atmel: introduce microchip csi2dc driver
On 18.11.2020 13:38, Jacopo Mondi wrote: > Hi Eugen, > > On Wed, Nov 18, 2020 at 09:48:19AM +, eugen.hris...@microchip.com wrote: >> On 18.11.2020 11:11, Jacopo Mondi wrote: >>> Hello Eugen, >>> > > [snip] > Hello, First of all thank you for the review and explanations. I am still confused about how does the userspace know which elements are in the pipeline and how to connect them ? >>> >>> Using the media-controller uAPI to inspect, explore and configure the >>> media graph (it's mostly about enabling and disabling media links), >>> and using the v4l2 subdev uAPI to configure formats, sizes and such on >>> each subdevice device node associated with a media entity. Finally, >>> using the v4l2 uAPI to stream from the top-level driver that expose a >>> video device node. >> >> Okay but which application in userspace uses this userAPI ? > > media-ctl which is part of v4l2-utils. > > existing applications or frameworks like gstreamer have no notion of > the platform they run on, they can't configure it, they only > understand '/dev/video0' > >> So I could use it to test my pipeline. >> > > The first step is to use media-ctl to manually setup the pipeline and > test. Once it's setup you can usually keep using the legacy > applications that only stream from /dev/video0. > > Of course manually setting up the pipeline using a script does not > scale, that's what the 'libcamera pipeline handler' does in facts. > It implements the same logic that you would manually apply with > media-ctl > >>> >>> It's really (conceptually) not different than doing the same using >>> media-ctl and v4l2-ctl. >>> And if this is the case, what is the purpose of the endpoints in the DT ? >>> >>> DTS describe the hardware. Usually a driver parses the firmware graph >>> to create and model the media graph and the available connections >>> between media entities but there's no requirement to have a 1-to-1 >>> match (as far I'm aware). >> >> So the top level v4l2 driver should parse the whole graph ? >> > > Userspace should :) > >>> >>> Media links on a media graph then need to be enabled opportunely >>> depending on the desired use case, the platform topology etc >>> At this moment, I just use the /dev/video0, because the top v4l2 driver configures the subdevice, and this subdevice configures it's own subdevice and so on, until the sensor itself. My top v4l2 driver will not 'complete' unless a subdevice registers itself , and if this subdevice does not provide any information regarding its formats, the probe of the top v4l2 driver will fail, because it will not find compatibility between it's supported input formats and what the subdevice provides. >>> >>> ouch, I see.. Which driver is that ? >> >> The atmel image sensor controller driver. >> All sensor drivers that we use (for example : ov5640, ov7740, ov7670) >> register as subdevices, and the atmel-isc will 'complete' when the >> sensor is probed and registered. > > That's ok, the complete callback is called when all the async devices > registered in a notifier are matched. > >> To have the csi2dc module compatible with what we have on atmel-isc, >> it's natural to have the csi2dc register itself as a subdevice such that >> the atmel-isc can 'complete'. > > the csi2d registering as subdev is all good (apart from the issue of > having 2 v4l2_device, but as you've see there's a solution for that > and it's called sub-notifiers). > > The 'issue' here is that your top driver wants to match formats to initialize > its supported format list (in isc_formats_init() from what I can see). > > An MC driver should not care about that. Each piece of the pipeline > has to be considered in isolation, and the format matching happens at > link_validate() time for links between subdevices and usually at > s_stream(1) time between sub-devices and video devices. > > In example, format enumeration on the video device registered by the > top v4l2 driver is conditional to the presence of the mbus_code field > as you can read in: > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-enum-fmt.html?highlight=enum_fmt#c.V4L.VIDIOC_ENUM_FMT > > And it should be possible by setting mbus_code = 0 to get a list of > all formats supported -by the hardware- not limited to the current use > case. > > Userspace knows the platform and if asked for 640x480[YUV420] will go > and set the right format on each piece of the pipeline, after having > enabled the relevant links, using the right media bus codes and sizes > > Totally random example: > > [video0] s_fmt(640x480, PIXFMT_YUV422) > (pad 0) > | > v > (pad 1) sudev_s_fmt(1, 640x480, MBUS_YUYV8_1X16) > [csi2dc] --- your subdev can crop --- > (pad 0) sudev_s_fmt(0, 648x496, MBUS_YUYV8_1X16) > | > V > (pad 0) subdev_s_fmt(0, 648x496,
Re: [PATCH v5 2/3] media: atmel: introduce microchip csi2dc driver
On 18.11.2020 11:11, Jacopo Mondi wrote: > Hello Eugen, > > On Tue, Nov 17, 2020 at 05:24:30PM +, eugen.hris...@microchip.com wrote: >> On 17.11.2020 14:09, Laurent Pinchart wrote: >>> Hello everybody, >>> >>> On Tue, Nov 17, 2020 at 12:59:02PM +0100, Jacopo Mondi wrote: On Thu, Nov 12, 2020 at 03:34:36PM +0200, Eugen Hristev wrote: > Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device > that converts a byte stream in IDI Synopsys format (coming from a > CSI2HOST) > to a pixel stream that can be captured by a sensor controller. > > Signed-off-by: Eugen Hristev > --- > Hello, > > There still are some open questions regarding the last reviews on the ML. > > Regarding the format list which is not const, I cannot have it const > because > I reference elements from this list into a dynamic list which is > non-const. > > Regarding the presence of the v4l2_dev, without this I cannot add a > notifier > for this device to have it async completed , when the underlying subdevice > finishes probing. I see you have a discussion with Sakari on-going on this, and I have the very same comment he had. Should a sub-notifier be used and this driver should not register any v4l2_dev but integrate in the media graph of the receiver ? For reference, rcar-csi2 uses sub-notifiers and register in the rcar-vin media graph, it doesn't need to set up a v4l2_dev. rcar-vin (the DMA engine driver) that register video nodes and the v4l2-dev also registers the device nodes for all the connected subdevices. >>> >>> Sub-notifiers were invited for this purpose, so I think they're the >>> right tool. >>> > Regarding the callbacks for set frame interval, set frame size, etc, I > cannot > remove them because losing functionality to the underlying subdevice, as > explained in : > https://lkml.org/lkml/2020/10/12/427 Using the frame sizes as in the example you reported, if this device has limitations on the supported sizes, (a min and a max most probably) that's the only thing that should be exposed from this driver subdevice. The sensor subdevice instead will report the available discrete sizes and userspace configures the sensor's source pad and the bridge's sink pad with the same sizes to properly set up the capture pipeline. video0 should not report the sizes exposed by the sensor nor any information that depends on what's connected to it. >>> >>> Agreed. Subdev drivers should remain simple and cover only the subdev >>> they manage. Bundling it together is the job of userspace. In the legacy >>> model it uses to be the job of the top-level V4L2 driver (the one >>> implementing v4l2_device), but that's legacy, especially for embedded >>> camera use cases. In any case, the top-level logic must not be spread >>> across subdevices. >>> I know what your next question is: what about existing application that only know about video0 and want to setup everything from there. I understand vendors not wanting to wrap gstreamer or what is used in the wild in custom scripts that sets up the pipeline opportunely before streaming, and I'm pretty sure you know what is the solution I would propose for this :) I've just gone through the same path with RPi's Unicam, that does the same thing as your one does: it's an MC driver, but wants to control the sensor through the v4l2-subdev kAPI to support legacy use cases not covered by libcamera. The fact is that we're stuck in this limbo where MC pipeline tries to decouple components one from each other and delegate their configuration to userspace, but at the same time vendors want to be able to use the simple plain video node centric interface because of their existing user base, so I understand your discomfort, but the 'simple plain' approach is what's preventing Linux platforms to be in-par with proprietary and custom solutions for any use case that is not a simple frame capture, so I think it's fair for mainline to push for this evolution to happen. Just my2c of course. >>> >>> Compatibility with the userspace of downstream kernels is important, but >>> that's a downstream kernel issue. In mainline we want to go the MC way, >>> and downstream can then, if desired, implement the configuration of the >>> pipeline in the top-level V4L2 driver in the kernel to support the >>> existing userbase. For new drivers I wouldn't recommend that, for >>> existing downstream drivers it may be required. >> >> Hello, >> >> First of all thank you for the review and explanations. >> >> I am still confused about how does the userspace know which elements are >> in the pipeline and how to connect them ? > > Using the media-controller uAPI to inspect, explore and configure the > media graph (it's mostly
Re: [PATCH v5 2/3] media: atmel: introduce microchip csi2dc driver
On 17.11.2020 14:09, Laurent Pinchart wrote: > Hello everybody, > > On Tue, Nov 17, 2020 at 12:59:02PM +0100, Jacopo Mondi wrote: >> On Thu, Nov 12, 2020 at 03:34:36PM +0200, Eugen Hristev wrote: >>> Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device >>> that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) >>> to a pixel stream that can be captured by a sensor controller. >>> >>> Signed-off-by: Eugen Hristev >>> --- >>> Hello, >>> >>> There still are some open questions regarding the last reviews on the ML. >>> >>> Regarding the format list which is not const, I cannot have it const because >>> I reference elements from this list into a dynamic list which is non-const. >>> >>> Regarding the presence of the v4l2_dev, without this I cannot add a notifier >>> for this device to have it async completed , when the underlying subdevice >>> finishes probing. >> >> I see you have a discussion with Sakari on-going on this, and I have >> the very same comment he had. >> >> Should a sub-notifier be used and this driver should not register any >> v4l2_dev but integrate in the media graph of the receiver ? >> >> For reference, rcar-csi2 uses sub-notifiers and register in the >> rcar-vin media graph, it doesn't need to set up a v4l2_dev. >> >> rcar-vin (the DMA engine driver) that register video nodes and the v4l2-dev >> also registers the device nodes for all the connected subdevices. > > Sub-notifiers were invited for this purpose, so I think they're the > right tool. > >>> Regarding the callbacks for set frame interval, set frame size, etc, I >>> cannot >>> remove them because losing functionality to the underlying subdevice, as >>> explained in : >>> https://lkml.org/lkml/2020/10/12/427 >> >> Using the frame sizes as in the example you reported, if this device has >> limitations on the supported sizes, (a min and a max most >> probably) that's the only thing that should be exposed from this >> driver subdevice. The sensor subdevice instead will report the >> available discrete sizes and userspace configures the sensor's source >> pad and the bridge's sink pad with the same sizes to properly set up the >> capture pipeline. video0 should not report the sizes exposed by the sensor >> nor any information that depends on what's connected to it. > > Agreed. Subdev drivers should remain simple and cover only the subdev > they manage. Bundling it together is the job of userspace. In the legacy > model it uses to be the job of the top-level V4L2 driver (the one > implementing v4l2_device), but that's legacy, especially for embedded > camera use cases. In any case, the top-level logic must not be spread > across subdevices. > >> I know what your next question is: what about existing application >> that only know about video0 and want to setup everything from there. I >> understand vendors not wanting to wrap gstreamer or what is used in >> the wild in custom scripts that sets up the pipeline opportunely >> before streaming, and I'm pretty sure you know what is the solution I >> would propose for this :) >> >> I've just gone through the same path with RPi's Unicam, that does the >> same thing as your one does: it's an MC driver, but wants to control >> the sensor through the v4l2-subdev kAPI to support legacy use cases >> not covered by libcamera. The fact is that we're stuck in this limbo >> where MC pipeline tries to decouple components one from each other and >> delegate their configuration to userspace, but at the same time >> vendors want to be able to use the simple plain video node centric >> interface because of their existing user base, so I understand your >> discomfort, but the 'simple plain' approach is what's preventing Linux >> platforms to be in-par with proprietary and custom solutions for any >> use case that is not a simple frame capture, so I think it's fair for >> mainline to push for this evolution to happen. Just my2c of course. > > Compatibility with the userspace of downstream kernels is important, but > that's a downstream kernel issue. In mainline we want to go the MC way, > and downstream can then, if desired, implement the configuration of the > pipeline in the top-level V4L2 driver in the kernel to support the > existing userbase. For new drivers I wouldn't recommend that, for > existing downstream drivers it may be required. Hello, First of all thank you for the review and explanations. I am still confused about how does the userspace know which elements are in the pipeline and how to connect them ? And if this is the case, what is the purpose of the endpoints in the DT ? At this moment, I just use the /dev/video0, because the top v4l2 driver configures the subdevice, and this subdevice configures it's own subdevice and so on, until the sensor itself. My top v4l2 driver will not 'complete' unless a subdevice registers itself , and if this subdevice does not provide any information regarding its formats, the probe of the top v4l2
Re: [PATCH v5 1/3] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc
On 17.11.2020 12:37, Jacopo Mondi wrote: > Hi again, > > On Thu, Nov 12, 2020 at 03:34:35PM +0200, Eugen Hristev wrote: >> Add bindings documentation for Microchip CSI2 Demultiplexer controller. >> >> CSI2DC is a demultiplexer from Synopsys IDI interface specification to >> parallel interface connection or direct memory access. >> >> Signed-off-by: Eugen Hristev >> --- >> Changes in v5: >> - modified bindings as per Rob Herring review >> >> Changes in v4: >> - Removed property for inter-line-delay and for clock >> continuous/non-continuous >> - Removed virtual channel by reg for second endpoint >> >> Changes in v3: >> - Removed some text from description, as it was explained in the schema >> - fixed other things as per Rob's review >> - moved some text inside the schema, like the clock description >> >> Changes in v2: >> - fixed warnings reported by dt_binding_check >> >> .../bindings/media/microchip,csi2dc.yaml | 119 ++ >> 1 file changed, 119 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> >> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> new file mode 100644 >> index ..e79f0d6ba9db >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> @@ -0,0 +1,119 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Microchip CSI2 Demux Controller (CSI2DC) >> + >> +maintainers: >> + - Eugen Hristev >> + >> +description: >> + CSI2DC - Camera Serial Interface 2 Demux Controller >> + >> + CSI2DC is a hardware block that receives incoming data from an IDI >> interface >> + and filters packets based on their data type and virtual channel >> identifier, >> + then converts the byte stream into a cross clock domain to a pixel stream >> + to a parallel interface that can be read by a sensor controller. >> + >> + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe >> + is connected to a sensor controller and the data pipe is accessible >> + as a DMA slave port to a DMA controller. >> + >> + CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit >> + IDI interface. The connected endpoint must be a IDI interface compatible >> + device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface >> + connection as sink pad. >> + For media entity and endpoints please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. >> + For Synopsys IDI interface please refer to >> + Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt > > Is it me or this file doesn't exists on the most recent media/master > and on v5.10-rc4 ? Hi Jacopo, Thanks for reviewing this patch. You are right. As I said at some point during the review, actually this controller has an input the IDI interface which is not currently in kernel. There is a patch series that adds the Synopsys platform driver, but nobody worked on it anymore and I use it for testing my driver. You can see the last version that was sent here: https://patchwork.linuxtv.org/project/linux-media/patch/1560280855-18085-2-git-send-email-luis.olive...@synopsys.com/ I sent this series to understand how to improve and how to get my driver in kernel, but indeed there are holes, especially this input type of bus which is not in the subsystem either. So how would you suggest to move forward ? Remove the reference to the synopsys binding and just leave 'IDI interface' which is undocumented ? Eugen > >> + >> + CSI2DC supports one 'port' node as sink pad with parallel interface. This >> is >> + called video pipe. >> + This port has an 'endpoint' can then be used as a source pad for another >> + controller (next in pipeline). >> + Please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. >> + >> + CSI2DC also supports direct access to the data through AHB, via DMA >> channel, >> + called data pipe. >> + Because of this, the sink 'port' child node (second) is not mandatory. >> + If the sink 'port' child node is missing, only data pipe is available. >> + >> +properties: >> + compatible: >> +const: microchip,sama7g5-csi2dc >> + >> + reg: >> +maxItems: 1 >> + >> + clocks: >> +maxItems: 2 >> + >> + clock-names: >> +description: >> + CSI2DC must have two clocks to function correctly. One clock is the >> + peripheral clock for the inside functionality of the hardware block. >> + This is named 'pclk'. The second clock must be the cross domain clock, >> + in which CSI2DC will perform clock crossing. This clock must be fed >> + by the next controller in pipeline, which usually
Re: [PATCH v3 1/3] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc
On 12.10.2020 16:04, Jacopo Mondi wrote: > Hello, > just my 2 cents, as I've noticed this patch skimming through the > list > > On Mon, Oct 12, 2020 at 07:19:43AM +, eugen.hris...@microchip.com wrote: >> On 11.10.2020 00:17, Laurent Pinchart wrote: >>> Hi Eugen, >>> >>> Thank you for the patch. >> >> Hi, >> >> Thank you for your review, >> >>> >>> On Wed, Aug 26, 2020 at 09:51:40AM +0300, Eugen Hristev wrote: Add bindings documentation for Microchip CSI2 Demultiplexer controller. CSI2DC is a demultiplexer from Synopsys IDI interface specification to parallel interface connection or direct memory access. Signed-off-by: Eugen Hristev --- Changes in v3: - Removed some text from description, as it was explained in the schema - fixed other things as per Rob's review - moved some text inside the schema, like the clock description Changes in v2: - fixed warnings reported by dt_binding_check .../bindings/media/microchip,csi2dc.yaml | 174 ++ 1 file changed, 174 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/microchip,csi2dc.yaml diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml new file mode 100644 index ..b4c1b8800a3b --- /dev/null +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip CSI2 Demux Controller (CSI2DC) + +maintainers: + - Eugen Hristev + +description: + CSI2DC - Camera Serial Interface 2 Demux Controller + + CSI2DC is a hardware block that receives incoming data from an IDI interface + and filters packets based on their data type and virtual channel identifier, + then converts the byte stream into a cross clock domain to a pixel stream + to a parallel interface that can be read by a sensor controller. + + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe + is connected to a sensor controller and the data pipe is accessible + as a DMA slave port to a DMA controller. + + CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit + IDI interface. The connected endpoint must be a IDI interface compatible + device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface + connection as sink pad. + For media entity and endpoints please refer to the bindings defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + For Synopsys IDI interface please refer to + Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt + + CSI2DC supports one 'port' node as sink pad with parallel interface. This is + called video pipe. + This port has an 'endpoint' can then be used as a source pad for another + controller (next in pipeline). + Please refer to the bindings defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + + CSI2DC also supports direct access to the data through AHB, via DMA channel, + called data pipe. + Because of this, the sink 'port' child node (second) is not mandatory. + If the sink 'port' child node is missing, only data pipe is available. + +properties: + compatible: +const: microchip,sama7g5-csi2dc + + reg: +maxItems: 1 + + clocks: +maxItems: 2 + + clock-names: +description: + CSI2DC must have two clocks to function correctly. One clock is the + peripheral clock for the inside functionality of the hardware block. + This is named 'pclk'. The second clock must be the cross domain clock, + in which CSI2DC will perform clock crossing. This clock must be fed + by the next controller in pipeline, which usually is a sensor controller. + Normally this clock should be given by this sensor controller who + is also a clock source. This clock is named 'scck', sensor controller clock. +items: + - const: pclk + - const: scck + + microchip,clk-gated: +type: boolean +description: + If present, indicates that the clock is gated. + Otherwise, the clock is free-running. >>> >>> I don't think this belongs to the DT bindings, it should instead be >>> queried from the source subdev at runtime. >> >> If this should be queried, do you know what is the v4l2 mechanism to
Re: [PATCH 6/7] dt-bindings: dmaengine: at_xdmac: add optional microchip,m2m property
On 16.10.2020 10:06, Vinod Koul wrote: > Hi Eugen, > > On 16-10-20, 06:45, eugen.hris...@microchip.com wrote: >> On 23.09.2020 02:33, Rob Herring wrote: >> >>> On Mon, Sep 14, 2020 at 05:09:55PM +0300, Eugen Hristev wrote: Add optional microchip,m2m property that specifies if a controller is dedicated to memory to memory operations only. Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/dma/atmel-xdma.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt index 510b7f25ba24..642da6b95a29 100644 --- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt +++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt @@ -15,6 +15,12 @@ the dmas property of client devices. interface identifier, - bit 30-24: PERID, peripheral identifier. +Optional properties: +- microchip,m2m: this controller is connected on AXI only to memory and it's + dedicated to memory to memory DMA operations. If this option is + missing, it's assumed that the DMA controller is connected to + peripherals, thus it's a per2mem and mem2per. >>> >>> Wouldn't 'dma-requests = <0>' cover this case? >>> >>> Rob >>> >> >> Hi Rob, >> >> I do not think so. With requests = 0, it means that actually the DMA >> controller is unusable ? >> Since you suggest requests = 0, it means that it cannot take requests at >> all ? >> I do not find another example in current DT with this property set to zero. > > Not really, dma-requests implies "request signals supported" which are > used for peripheral cases. m2m does not need request signals, so it is > very reasonable to conclude that dma-requests = <0> would imply no > peripheral support and only m2m support. Thanks for explaining, I will change accordingly then. Eugen > > Thanks > -- > ~Vinod >
Re: [PATCH 5/7] dmaengine: at_xdmac: add support for sama7g5 based at_xdmac
On 23.09.2020 10:08, Tudor Ambarus - M18064 wrote:
> On 9/14/20 5:09 PM, Eugen Hristev wrote:
>> SAMA7G5 SoC uses a slightly different variant of the AT_XDMAC.
>> Added support by a new compatible and a layout struct that copes
>> to the specific version considering the compatible string.
>> Only the differences in register map are present in the layout struct.
>> I reworked the register access for this part that has the differences.
>> Also the Source/Destination Interface bits are no longer valid for this
>> variant of the XDMAC. Thus, the layout also has a bool for specifying
>> whether these bits are required or not.
>>
>> Signed-off-by: Eugen Hristev
>> ---
>> drivers/dma/at_xdmac.c | 99 ++---
>> drivers/dma/at_xdmac_regs.h | 9
>> 2 files changed, 82 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
>> index 81bb90206092..874484a4e79f 100644
>> --- a/drivers/dma/at_xdmac.c
>> +++ b/drivers/dma/at_xdmac.c
>> @@ -38,6 +38,27 @@ enum atc_status {
>> AT_XDMAC_CHAN_IS_PAUSED,
>> };
>>
>> +struct at_xdmac_layout {
>> +/* Global Channel Read Suspend Register */
>> +u8 grs;
>> +/* Global Write Suspend Register */
>> +u8 gws;
>> +/* Global Channel Read Write Suspend Register */
>> +u8 grws;
>> +/* Global Channel Read Write Resume Register */
>> +u8 grwr;
>> +/* Global Channel Software Request Register */
>> +u8 gswr;
>> +/* Global channel Software Request Status Register */
>> +u8 gsws;
>> +/* Global Channel Software Flush Request Register */
>> +u8 gswf;
>> +/* Channel reg base */
>> +u8 chan_cc_reg_base;
>> +/* Source/Destination Interface must be specified or not */
>> +boolsdif;
>> +};
>> +
>> /* - Channels - */
>> struct at_xdmac_chan {
>> struct dma_chan chan;
>> @@ -71,6 +92,7 @@ struct at_xdmac {
>> struct clk *clk;
>> u32 save_gim;
>> struct dma_pool *at_xdmac_desc_pool;
>> +const struct at_xdmac_layout*layout;
>> struct at_xdmac_chanchan[];
>> };
>>
>> @@ -103,9 +125,33 @@ struct at_xdmac_desc {
>> struct list_headxfer_node;
>> } __aligned(sizeof(u64));
>>
>> +static struct at_xdmac_layout at_xdmac_sama5d4_layout = {
>
> static const struct
>
>> +.grs = 0x28,
>> +.gws = 0x2C,
>> +.grws = 0x30,
>> +.grwr = 0x34,
>> +.gswr = 0x38,
>> +.gsws = 0x3C,
>> +.gswf = 0x40,
>> +.chan_cc_reg_base = 0x50,
>> +.sdif = true,
>> +};
>> +
>> +static struct at_xdmac_layout at_xdmac_sama7g5_layout = {
>
> static const struct
>
>> +.grs = 0x30,
>> +.gws = 0x38,
>> +.grws = 0x40,
>> +.grwr = 0x44,
>> +.gswr = 0x48,
>> +.gsws = 0x4C,
>> +.gswf = 0x50,
>> +.chan_cc_reg_base = 0x60,
>
> one may find these plain offsets as too raw and probably prefer some defines
> for them, but I too think that the members of the struct are self-explanatory,
> so I'm ok either way.
>
>> +.sdif = false,
>> +};
>> +
>> static inline void __iomem *at_xdmac_chan_reg_base(struct at_xdmac
>> *atxdmac, unsigned int chan_nb)
>> {
>> -return atxdmac->regs + (AT_XDMAC_CHAN_REG_BASE + chan_nb * 0x40);
>> +return atxdmac->regs + (atxdmac->layout->chan_cc_reg_base + chan_nb *
>> 0x40);
>> }
>>
>> #define at_xdmac_read(atxdmac, reg) readl_relaxed((atxdmac)->regs + (reg))
>> @@ -204,8 +250,10 @@ static void at_xdmac_start_xfer(struct at_xdmac_chan
>> *atchan,
>> first->active_xfer = true;
>>
>> /* Tell xdmac where to get the first descriptor. */
>> -reg = AT_XDMAC_CNDA_NDA(first->tx_dma_desc.phys)
>> - | AT_XDMAC_CNDA_NDAIF(atchan->memif);
>> +reg = AT_XDMAC_CNDA_NDA(first->tx_dma_desc.phys);
>> +if (atxdmac->layout->sdif)
>> +reg |= AT_XDMAC_CNDA_NDAIF(atchan->memif);
>> +
>> at_xdmac_chan_write(atchan, AT_XDMAC_CNDA, reg);
>>
>> /*
>> @@ -400,6 +448,7 @@ static int at_xdmac_compute_chan_conf(struct dma_chan
>> *chan,
>>enum dma_transfer_direction direction)
>> {
>> struct at_xdmac_chan*atchan = to_at_xdmac_chan(chan);
>> +struct at_xdmac *atxdmac = to_at_xdmac(atchan->chan.device);
>> int csize, dwidth;
>>
>> if (direction == DMA_DEV_TO_MEM) {
>> @@ -407,12 +456,14 @@ static int at_xdmac_compute_chan_conf(struct dma_chan
>> *chan,
>> AT91_XDMAC_DT_PERID(atchan->perid)
>> | AT_XDMAC_CC_DAM_INCREMENTED_AM
>> | AT_XDMAC_CC_SAM_FIXED_AM
>> -|
Re: [PATCH 6/7] dt-bindings: dmaengine: at_xdmac: add optional microchip,m2m property
On 23.09.2020 02:33, Rob Herring wrote: > On Mon, Sep 14, 2020 at 05:09:55PM +0300, Eugen Hristev wrote: >> Add optional microchip,m2m property that specifies if a controller is >> dedicated to memory to memory operations only. >> >> Signed-off-by: Eugen Hristev >> --- >> Documentation/devicetree/bindings/dma/atmel-xdma.txt | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt >> b/Documentation/devicetree/bindings/dma/atmel-xdma.txt >> index 510b7f25ba24..642da6b95a29 100644 >> --- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt >> +++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt >> @@ -15,6 +15,12 @@ the dmas property of client devices. >> interface identifier, >> - bit 30-24: PERID, peripheral identifier. >> >> +Optional properties: >> +- microchip,m2m: this controller is connected on AXI only to memory and it's >> + dedicated to memory to memory DMA operations. If this option is >> + missing, it's assumed that the DMA controller is connected to >> + peripherals, thus it's a per2mem and mem2per. > > Wouldn't 'dma-requests = <0>' cover this case? > > Rob > Hi Rob, I do not think so. With requests = 0, it means that actually the DMA controller is unusable ? Since you suggest requests = 0, it means that it cannot take requests at all ? I do not find another example in current DT with this property set to zero. Eugen
Re: [PATCH v3 2/3] media: atmel: introduce microchip csi2dc driver
On 12.10.2020 10:15, Eugen Hristev - M18282 wrote: > On 09.10.2020 17:58, Sakari Ailus wrote: > >> Hi Eugen, >> >> My apologies for the late reply. >> > > Hi, > > Thank you for replying, > >> On Mon, Sep 07, 2020 at 09:16:57AM +, eugen.hris...@microchip.com wrote: >>> On 31.08.2020 11:50, Sakari Ailus wrote: >>> Hi Eugen, Thanks for the update. >>> >>> Hi Sakari, >>> >>> Thanks for reviewing, but, could you please help me understand your >>> review below ? >>> On Wed, Aug 26, 2020 at 09:51:41AM +0300, Eugen Hristev wrote: > Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device > that converts a byte stream in IDI Synopsys format (coming from a > CSI2HOST) > to a pixel stream that can be captured by a sensor controller. > > Signed-off-by: Eugen Hristev > --- > Changes in v2: > - moved driver to platform/atmel > - fixed minor things as per Sakari's review > - still some things from v2 review are not yet addressed, to be followed > up > > drivers/media/platform/atmel/Kconfig | 13 + > drivers/media/platform/atmel/Makefile | 1 + > .../media/platform/atmel/microchip-csi2dc.c | 700 ++ > 3 files changed, 714 insertions(+) > create mode 100644 drivers/media/platform/atmel/microchip-csi2dc.c > > diff --git a/drivers/media/platform/atmel/Kconfig > b/drivers/media/platform/atmel/Kconfig > index 1850fe7f9360..80bbddcc2504 100644 > --- a/drivers/media/platform/atmel/Kconfig > +++ b/drivers/media/platform/atmel/Kconfig > @@ -21,3 +21,16 @@ config VIDEO_ATMEL_ISI > help >This module makes the ATMEL Image Sensor Interface available >as a v4l2 device. > + > +config VIDEO_MICROCHIP_CSI2DC > + tristate "Microchip CSI2 Demux Controller" > + depends on VIDEO_V4L2 && COMMON_CLK && OF > + depends on ARCH_AT91 || COMPILE_TEST > + select MEDIA_CONTROLLER > + select VIDEO_V4L2_SUBDEV_API > + select V4L2_FWNODE > + help > + CSI2 Demux Controller driver. CSI2DC is a helper chip > + that converts IDI interface byte stream to a parallel pixel > stream. > + It supports various RAW formats as input. > + Performs clock domain crossing between hardware blocks. > diff --git a/drivers/media/platform/atmel/Makefile > b/drivers/media/platform/atmel/Makefile > index 2dba38994a70..8af7c5b534c3 100644 > --- a/drivers/media/platform/atmel/Makefile > +++ b/drivers/media/platform/atmel/Makefile > @@ -3,3 +3,4 @@ atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o > > obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o > obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o > +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip-csi2dc.o > diff --git a/drivers/media/platform/atmel/microchip-csi2dc.c > b/drivers/media/platform/atmel/microchip-csi2dc.c > new file mode 100644 > index ..97d07a80bbf7 > --- /dev/null > +++ b/drivers/media/platform/atmel/microchip-csi2dc.c > @@ -0,0 +1,700 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Microchip CSI2 Demux Controller (CSI2DC) driver > + * > + * Copyright (C) 2018-2020 Microchip Technology, Inc. > + * > + * Author: Eugen Hristev > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +/* Global configuration register */ > +#define CSI2DC_GCFG 0x0 > + > +/* MIPI sensor pixel clock is free running */ > +#define CSI2DC_GCFG_MIPIFRN BIT(0) > +/* Output waveform inter-line minimum delay */ > +#define CSI2DC_GCFG_HLC(v) ((v) << 4) > +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) > + > +/* Global control register */ > +#define CSI2DC_GCTLR 0x04 > +#define CSI2DC_GCTLR_SWRST BIT(0) > + > +/* Global status register */ > +#define CSI2DC_GS0x08 > + > +/* SSP interrupt status register */ > +#define CSI2DC_SSPIS 0x28 > +/* Pipe update register */ > +#define CSI2DC_PU0xC0 > +/* Video pipe attributes update */ > +#define CSI2DC_PU_VP BIT(0) > + > +/* Pipe update status register */ > +#define CSI2DC_PUS 0xC4 > + > +/* Video pipeline enable register */ > +#define CSI2DC_VPE 0xF8 > +#define CSI2DC_VPE_ENABLEBIT(0) > + > +/* Video pipeline configuration register */ > +#define CSI2DC_VPCFG 0xFC > +/* Data type */ > +#define CSI2DC_VPCFG_DT(v)
Re: [PATCH v3 1/3] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc
On 11.10.2020 00:17, Laurent Pinchart wrote: > Hi Eugen, > > Thank you for the patch. Hi, Thank you for your review, > > On Wed, Aug 26, 2020 at 09:51:40AM +0300, Eugen Hristev wrote: >> Add bindings documentation for Microchip CSI2 Demultiplexer controller. >> >> CSI2DC is a demultiplexer from Synopsys IDI interface specification to >> parallel interface connection or direct memory access. >> >> Signed-off-by: Eugen Hristev >> --- >> Changes in v3: >> - Removed some text from description, as it was explained in the schema >> - fixed other things as per Rob's review >> - moved some text inside the schema, like the clock description >> >> Changes in v2: >> - fixed warnings reported by dt_binding_check >> >> .../bindings/media/microchip,csi2dc.yaml | 174 ++ >> 1 file changed, 174 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> >> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> new file mode 100644 >> index ..b4c1b8800a3b >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> @@ -0,0 +1,174 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Microchip CSI2 Demux Controller (CSI2DC) >> + >> +maintainers: >> + - Eugen Hristev >> + >> +description: >> + CSI2DC - Camera Serial Interface 2 Demux Controller >> + >> + CSI2DC is a hardware block that receives incoming data from an IDI >> interface >> + and filters packets based on their data type and virtual channel >> identifier, >> + then converts the byte stream into a cross clock domain to a pixel stream >> + to a parallel interface that can be read by a sensor controller. >> + >> + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe >> + is connected to a sensor controller and the data pipe is accessible >> + as a DMA slave port to a DMA controller. >> + >> + CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit >> + IDI interface. The connected endpoint must be a IDI interface compatible >> + device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface >> + connection as sink pad. >> + For media entity and endpoints please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. >> + For Synopsys IDI interface please refer to >> + Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt >> + >> + CSI2DC supports one 'port' node as sink pad with parallel interface. This >> is >> + called video pipe. >> + This port has an 'endpoint' can then be used as a source pad for another >> + controller (next in pipeline). >> + Please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. >> + >> + CSI2DC also supports direct access to the data through AHB, via DMA >> channel, >> + called data pipe. >> + Because of this, the sink 'port' child node (second) is not mandatory. >> + If the sink 'port' child node is missing, only data pipe is available. >> + >> +properties: >> + compatible: >> +const: microchip,sama7g5-csi2dc >> + >> + reg: >> +maxItems: 1 >> + >> + clocks: >> +maxItems: 2 >> + >> + clock-names: >> +description: >> + CSI2DC must have two clocks to function correctly. One clock is the >> + peripheral clock for the inside functionality of the hardware block. >> + This is named 'pclk'. The second clock must be the cross domain clock, >> + in which CSI2DC will perform clock crossing. This clock must be fed >> + by the next controller in pipeline, which usually is a sensor >> controller. >> + Normally this clock should be given by this sensor controller who >> + is also a clock source. This clock is named 'scck', sensor controller >> clock. >> +items: >> + - const: pclk >> + - const: scck >> + >> + microchip,clk-gated: >> +type: boolean >> +description: >> + If present, indicates that the clock is gated. >> + Otherwise, the clock is free-running. > > I don't think this belongs to the DT bindings, it should instead be > queried from the source subdev at runtime. If this should be queried, do you know what is the v4l2 mechanism to query such information ? The subdevice is connected through a port interface to this device, so it was natural for me to fully describe the interface in the devicetree port description > >> + >> + microchip,inter-line-delay: >> +allOf: >> +- $ref: /schemas/types.yaml#/definitions/uint32 >> +- minimum: 1 >> +- maximum: 16 >> +default: 16 >> +description: >> + Indicates how many clock cycles should be introduced between each >> line. > >
Re: [PATCH v3 2/3] media: atmel: introduce microchip csi2dc driver
On 09.10.2020 17:58, Sakari Ailus wrote: > Hi Eugen, > > My apologies for the late reply. > Hi, Thank you for replying, > On Mon, Sep 07, 2020 at 09:16:57AM +, eugen.hris...@microchip.com wrote: >> On 31.08.2020 11:50, Sakari Ailus wrote: >> >>> Hi Eugen, >>> >>> Thanks for the update. >> >> Hi Sakari, >> >> Thanks for reviewing, but, could you please help me understand your >> review below ? >> >>> >>> On Wed, Aug 26, 2020 at 09:51:41AM +0300, Eugen Hristev wrote: Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) to a pixel stream that can be captured by a sensor controller. Signed-off-by: Eugen Hristev --- Changes in v2: - moved driver to platform/atmel - fixed minor things as per Sakari's review - still some things from v2 review are not yet addressed, to be followed up drivers/media/platform/atmel/Kconfig | 13 + drivers/media/platform/atmel/Makefile | 1 + .../media/platform/atmel/microchip-csi2dc.c | 700 ++ 3 files changed, 714 insertions(+) create mode 100644 drivers/media/platform/atmel/microchip-csi2dc.c diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig index 1850fe7f9360..80bbddcc2504 100644 --- a/drivers/media/platform/atmel/Kconfig +++ b/drivers/media/platform/atmel/Kconfig @@ -21,3 +21,16 @@ config VIDEO_ATMEL_ISI help This module makes the ATMEL Image Sensor Interface available as a v4l2 device. + +config VIDEO_MICROCHIP_CSI2DC + tristate "Microchip CSI2 Demux Controller" + depends on VIDEO_V4L2 && COMMON_CLK && OF + depends on ARCH_AT91 || COMPILE_TEST + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + select V4L2_FWNODE + help + CSI2 Demux Controller driver. CSI2DC is a helper chip + that converts IDI interface byte stream to a parallel pixel stream. + It supports various RAW formats as input. + Performs clock domain crossing between hardware blocks. diff --git a/drivers/media/platform/atmel/Makefile b/drivers/media/platform/atmel/Makefile index 2dba38994a70..8af7c5b534c3 100644 --- a/drivers/media/platform/atmel/Makefile +++ b/drivers/media/platform/atmel/Makefile @@ -3,3 +3,4 @@ atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip-csi2dc.o diff --git a/drivers/media/platform/atmel/microchip-csi2dc.c b/drivers/media/platform/atmel/microchip-csi2dc.c new file mode 100644 index ..97d07a80bbf7 --- /dev/null +++ b/drivers/media/platform/atmel/microchip-csi2dc.c @@ -0,0 +1,700 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Microchip CSI2 Demux Controller (CSI2DC) driver + * + * Copyright (C) 2018-2020 Microchip Technology, Inc. + * + * Author: Eugen Hristev + * + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +/* Global configuration register */ +#define CSI2DC_GCFG 0x0 + +/* MIPI sensor pixel clock is free running */ +#define CSI2DC_GCFG_MIPIFRN BIT(0) +/* Output waveform inter-line minimum delay */ +#define CSI2DC_GCFG_HLC(v) ((v) << 4) +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) + +/* Global control register */ +#define CSI2DC_GCTLR 0x04 +#define CSI2DC_GCTLR_SWRST BIT(0) + +/* Global status register */ +#define CSI2DC_GS0x08 + +/* SSP interrupt status register */ +#define CSI2DC_SSPIS 0x28 +/* Pipe update register */ +#define CSI2DC_PU0xC0 +/* Video pipe attributes update */ +#define CSI2DC_PU_VP BIT(0) + +/* Pipe update status register */ +#define CSI2DC_PUS 0xC4 + +/* Video pipeline enable register */ +#define CSI2DC_VPE 0xF8 +#define CSI2DC_VPE_ENABLEBIT(0) + +/* Video pipeline configuration register */ +#define CSI2DC_VPCFG 0xFC +/* Data type */ +#define CSI2DC_VPCFG_DT(v) ((v) << 0) +#define CSI2DC_VPCFG_DT_MASK GENMASK(5, 0) +/* Virtual channel identifier */ +#define CSI2DC_VPCFG_VC(v) ((v) << 6) +#define CSI2DC_VPCFG_VC_MASK GENMASK(7, 6)
Re: [PATCH v3 2/3] media: atmel: introduce microchip csi2dc driver
On 07.09.2020 12:16, Eugen Hristev - M18282 wrote: > On 31.08.2020 11:50, Sakari Ailus wrote: > >> Hi Eugen, >> >> Thanks for the update. > > Hi Sakari, > > Thanks for reviewing, but, could you please help me understand your > review below ? > Gentle ping Thanks >> >> On Wed, Aug 26, 2020 at 09:51:41AM +0300, Eugen Hristev wrote: >>> Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device >>> that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) >>> to a pixel stream that can be captured by a sensor controller. >>> >>> Signed-off-by: Eugen Hristev >>> --- >>> Changes in v2: >>> - moved driver to platform/atmel >>> - fixed minor things as per Sakari's review >>> - still some things from v2 review are not yet addressed, to be followed up >>> >>>drivers/media/platform/atmel/Kconfig | 13 + >>>drivers/media/platform/atmel/Makefile | 1 + >>>.../media/platform/atmel/microchip-csi2dc.c | 700 ++ >>>3 files changed, 714 insertions(+) >>>create mode 100644 drivers/media/platform/atmel/microchip-csi2dc.c >>> >>> diff --git a/drivers/media/platform/atmel/Kconfig >>> b/drivers/media/platform/atmel/Kconfig >>> index 1850fe7f9360..80bbddcc2504 100644 >>> --- a/drivers/media/platform/atmel/Kconfig >>> +++ b/drivers/media/platform/atmel/Kconfig >>> @@ -21,3 +21,16 @@ config VIDEO_ATMEL_ISI >>> help >>> This module makes the ATMEL Image Sensor Interface available >>> as a v4l2 device. >>> + >>> +config VIDEO_MICROCHIP_CSI2DC >>> + tristate "Microchip CSI2 Demux Controller" >>> + depends on VIDEO_V4L2 && COMMON_CLK && OF >>> + depends on ARCH_AT91 || COMPILE_TEST >>> + select MEDIA_CONTROLLER >>> + select VIDEO_V4L2_SUBDEV_API >>> + select V4L2_FWNODE >>> + help >>> + CSI2 Demux Controller driver. CSI2DC is a helper chip >>> + that converts IDI interface byte stream to a parallel pixel stream. >>> + It supports various RAW formats as input. >>> + Performs clock domain crossing between hardware blocks. >>> diff --git a/drivers/media/platform/atmel/Makefile >>> b/drivers/media/platform/atmel/Makefile >>> index 2dba38994a70..8af7c5b534c3 100644 >>> --- a/drivers/media/platform/atmel/Makefile >>> +++ b/drivers/media/platform/atmel/Makefile >>> @@ -3,3 +3,4 @@ atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o >>> >>>obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o >>>obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o >>> +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip-csi2dc.o >>> diff --git a/drivers/media/platform/atmel/microchip-csi2dc.c >>> b/drivers/media/platform/atmel/microchip-csi2dc.c >>> new file mode 100644 >>> index ..97d07a80bbf7 >>> --- /dev/null >>> +++ b/drivers/media/platform/atmel/microchip-csi2dc.c >>> @@ -0,0 +1,700 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Microchip CSI2 Demux Controller (CSI2DC) driver >>> + * >>> + * Copyright (C) 2018-2020 Microchip Technology, Inc. >>> + * >>> + * Author: Eugen Hristev >>> + * >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +/* Global configuration register */ >>> +#define CSI2DC_GCFG 0x0 >>> + >>> +/* MIPI sensor pixel clock is free running */ >>> +#define CSI2DC_GCFG_MIPIFRN BIT(0) >>> +/* Output waveform inter-line minimum delay */ >>> +#define CSI2DC_GCFG_HLC(v) ((v) << 4) >>> +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) >>> + >>> +/* Global control register */ >>> +#define CSI2DC_GCTLR 0x04 >>> +#define CSI2DC_GCTLR_SWRST BIT(0) >>> + >>> +/* Global status register */ >>> +#define CSI2DC_GS0x08 >>> + >>> +/* SSP interrupt status register */ >>> +#define CSI2DC_SSPIS 0x28 >>> +/* Pipe update register */ >>> +#define CSI2DC_PU0xC0 >>> +/* Video pipe attributes update */ >>> +#define CSI2DC_PU_VP BIT(0) >>> + >>> +/* Pipe update status register */ >>> +#define CSI2DC_PUS 0xC4 >>> + >>> +/* Video pipeline enable register */ >>> +#define CSI2DC_VPE 0xF8 >>> +#define CSI2DC_VPE_ENABLEBIT(0) >>> + >>> +/* Video pipeline configuration register */ >>> +#define CSI2DC_VPCFG 0xFC >>> +/* Data type */ >>> +#define CSI2DC_VPCFG_DT(v) ((v) << 0) >>> +#define CSI2DC_VPCFG_DT_MASK GENMASK(5, 0) >>> +/* Virtual channel identifier */ >>> +#define CSI2DC_VPCFG_VC(v) ((v) << 6) >>> +#define CSI2DC_VPCFG_VC_MASK GENMASK(7, 6) >>> +/* Decompression enable */ >>> +#define CSI2DC_VPCFG_DE BIT(8) >>> +/* Decoder mode */ >>> +#define CSI2DC_VPCFG_DM(v) ((v) << 9) >>> +#define CSI2DC_VPCFG_DM_DECODER8TO12 0 >>> +/* Decoder predictor 2 selection */ >>> +#define
Re: [PATCH v3 2/3] media: atmel: introduce microchip csi2dc driver
On 31.08.2020 11:50, Sakari Ailus wrote: > Hi Eugen, > > Thanks for the update. Hi Sakari, Thanks for reviewing, but, could you please help me understand your review below ? > > On Wed, Aug 26, 2020 at 09:51:41AM +0300, Eugen Hristev wrote: >> Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device >> that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) >> to a pixel stream that can be captured by a sensor controller. >> >> Signed-off-by: Eugen Hristev >> --- >> Changes in v2: >> - moved driver to platform/atmel >> - fixed minor things as per Sakari's review >> - still some things from v2 review are not yet addressed, to be followed up >> >> drivers/media/platform/atmel/Kconfig | 13 + >> drivers/media/platform/atmel/Makefile | 1 + >> .../media/platform/atmel/microchip-csi2dc.c | 700 ++ >> 3 files changed, 714 insertions(+) >> create mode 100644 drivers/media/platform/atmel/microchip-csi2dc.c >> >> diff --git a/drivers/media/platform/atmel/Kconfig >> b/drivers/media/platform/atmel/Kconfig >> index 1850fe7f9360..80bbddcc2504 100644 >> --- a/drivers/media/platform/atmel/Kconfig >> +++ b/drivers/media/platform/atmel/Kconfig >> @@ -21,3 +21,16 @@ config VIDEO_ATMEL_ISI >>help >> This module makes the ATMEL Image Sensor Interface available >> as a v4l2 device. >> + >> +config VIDEO_MICROCHIP_CSI2DC >> + tristate "Microchip CSI2 Demux Controller" >> + depends on VIDEO_V4L2 && COMMON_CLK && OF >> + depends on ARCH_AT91 || COMPILE_TEST >> + select MEDIA_CONTROLLER >> + select VIDEO_V4L2_SUBDEV_API >> + select V4L2_FWNODE >> + help >> + CSI2 Demux Controller driver. CSI2DC is a helper chip >> + that converts IDI interface byte stream to a parallel pixel stream. >> + It supports various RAW formats as input. >> + Performs clock domain crossing between hardware blocks. >> diff --git a/drivers/media/platform/atmel/Makefile >> b/drivers/media/platform/atmel/Makefile >> index 2dba38994a70..8af7c5b534c3 100644 >> --- a/drivers/media/platform/atmel/Makefile >> +++ b/drivers/media/platform/atmel/Makefile >> @@ -3,3 +3,4 @@ atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o >> >> obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o >> obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o >> +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip-csi2dc.o >> diff --git a/drivers/media/platform/atmel/microchip-csi2dc.c >> b/drivers/media/platform/atmel/microchip-csi2dc.c >> new file mode 100644 >> index ..97d07a80bbf7 >> --- /dev/null >> +++ b/drivers/media/platform/atmel/microchip-csi2dc.c >> @@ -0,0 +1,700 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Microchip CSI2 Demux Controller (CSI2DC) driver >> + * >> + * Copyright (C) 2018-2020 Microchip Technology, Inc. >> + * >> + * Author: Eugen Hristev >> + * >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> + >> +/* Global configuration register */ >> +#define CSI2DC_GCFG 0x0 >> + >> +/* MIPI sensor pixel clock is free running */ >> +#define CSI2DC_GCFG_MIPIFRN BIT(0) >> +/* Output waveform inter-line minimum delay */ >> +#define CSI2DC_GCFG_HLC(v) ((v) << 4) >> +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) >> + >> +/* Global control register */ >> +#define CSI2DC_GCTLR 0x04 >> +#define CSI2DC_GCTLR_SWRST BIT(0) >> + >> +/* Global status register */ >> +#define CSI2DC_GS0x08 >> + >> +/* SSP interrupt status register */ >> +#define CSI2DC_SSPIS 0x28 >> +/* Pipe update register */ >> +#define CSI2DC_PU0xC0 >> +/* Video pipe attributes update */ >> +#define CSI2DC_PU_VP BIT(0) >> + >> +/* Pipe update status register */ >> +#define CSI2DC_PUS 0xC4 >> + >> +/* Video pipeline enable register */ >> +#define CSI2DC_VPE 0xF8 >> +#define CSI2DC_VPE_ENABLEBIT(0) >> + >> +/* Video pipeline configuration register */ >> +#define CSI2DC_VPCFG 0xFC >> +/* Data type */ >> +#define CSI2DC_VPCFG_DT(v) ((v) << 0) >> +#define CSI2DC_VPCFG_DT_MASK GENMASK(5, 0) >> +/* Virtual channel identifier */ >> +#define CSI2DC_VPCFG_VC(v) ((v) << 6) >> +#define CSI2DC_VPCFG_VC_MASK GENMASK(7, 6) >> +/* Decompression enable */ >> +#define CSI2DC_VPCFG_DE BIT(8) >> +/* Decoder mode */ >> +#define CSI2DC_VPCFG_DM(v) ((v) << 9) >> +#define CSI2DC_VPCFG_DM_DECODER8TO12 0 >> +/* Decoder predictor 2 selection */ >> +#define CSI2DC_VPCFG_DP2 BIT(12) >> +/* Recommended memory storage */ >> +#define CSI2DC_VPCFG_RMS BIT(13) >> +/* Post adjustment */ >> +#define CSI2DC_VPCFG_PA BIT(14) >> + >> +/* Video
Re: [PATCH v2 3/4] media: misc: introduce microchip_csi2dc driver
On 25.08.2020 15:44, Eugen Hristev - M18282 wrote: > On 14.08.2020 01:44, Sakari Ailus wrote: > >> Hi Eugen, >> >> Thanks for the patch. > > Hello Sakari, > > Thanks for reviewing. > >> >> On Fri, Jul 03, 2020 at 10:44:15AM +0300, Eugen Hristev wrote: >>> Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device >>> that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) >>> to a pixel stream that can be captured by a sensor controller. >>> >>> Signed-off-by: Eugen Hristev >>> --- >>>drivers/media/misc/Kconfig| 9 + >>>drivers/media/misc/Makefile | 1 + >>>drivers/media/misc/microchip_csi2dc.c | 705 ++ >>>3 files changed, 715 insertions(+) >>>create mode 100644 drivers/media/misc/microchip_csi2dc.c >>> >>> diff --git a/drivers/media/misc/Kconfig b/drivers/media/misc/Kconfig >>> index 206f39f86f46..86e892a41eba 100644 >>> --- a/drivers/media/misc/Kconfig >>> +++ b/drivers/media/misc/Kconfig >>> @@ -8,6 +8,15 @@ menu "Miscellaneous helper chips" >>> >>>comment "Various helper chips" >>> >>> +config VIDEO_MICROCHIP_CSI2DC >>> + tristate "Microchip CSI2 Demux Controller" >>> + depends on VIDEO_V4L2 >>> + help >>> + CSI2 Demux Controller driver. CSI2DC is a helper chip >>> + that converts IDI interface byte stream to a parallel pixel stream. >>> + It supports various RAW formats as input. >>> + Performs clock domain crossing between hardware blocks. >>> + >>>endmenu >>> >>>endif >>> diff --git a/drivers/media/misc/Makefile b/drivers/media/misc/Makefile >>> index f66554cd5c45..86477781b7af 100644 >>> --- a/drivers/media/misc/Makefile >>> +++ b/drivers/media/misc/Makefile >>> @@ -1 +1,2 @@ >>># SPDX-License-Identifier: GPL-2.0 >>> +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip_csi2dc.o >>> diff --git a/drivers/media/misc/microchip_csi2dc.c >>> b/drivers/media/misc/microchip_csi2dc.c >>> new file mode 100644 >>> index ..494b7c137b17 >>> --- /dev/null >>> +++ b/drivers/media/misc/microchip_csi2dc.c >>> @@ -0,0 +1,705 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Microchip CSI2 Demux Controller (CSI2DC) driver >>> + * >>> + * Copyright (C) 2018-2020 Microchip Technology, Inc. >>> + * >>> + * Author: Eugen Hristev >>> + * >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +/* Global configuration register */ >>> +#define CSI2DC_GCFG 0x0 >>> + >>> +/* MIPI sensor pixel clock is free running */ >>> +#define CSI2DC_GCFG_MIPIFRN BIT(0) >>> +/* Output waveform inter-line minimum delay */ >>> +#define CSI2DC_GCFG_HLC(v) ((v) << 4) >>> +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) >>> + >>> +/* Global control register */ >>> +#define CSI2DC_GCTLR 0x04 >>> +#define CSI2DC_GCTLR_SWRST BIT(0) >>> + >>> +/* Global status register */ >>> +#define CSI2DC_GS0x08 >>> + >>> +/* SSP interrupt status register */ >>> +#define CSI2DC_SSPIS 0x28 >>> +/* Pipe update register */ >>> +#define CSI2DC_PU0xC0 >>> +/* Video pipe attributes update */ >>> +#define CSI2DC_PU_VP BIT(0) >>> + >>> +/* Pipe update status register */ >>> +#define CSI2DC_PUS 0xC4 >>> + >>> +/* Video pipeline enable register */ >>> +#define CSI2DC_VPE 0xF8 >>> +#define CSI2DC_VPE_ENABLEBIT(0) >>> + >>> +/* Video pipeline configuration register */ >>> +#define CSI2DC_VPCFG 0xFC >>> +/* Data type */ >>> +#define CSI2DC_VPCFG_DT(v) ((v) << 0) >>> +#define CSI2DC_VPCFG_DT_MASK GENMASK(5, 0) >>> +/* Virtual channel identifier */ >>> +#define CSI2DC_VPCFG_VC(v) ((v) << 6) >>> +#define CSI2DC_VPCFG_VC_MASK GENMASK(7, 6) >>> +/* Decompression enable */ >>> +#define CSI2DC_VPCFG_DE BIT(8) >>> +/* Decoder mode */ >>> +#define CSI2DC_VPCFG_DM(v) ((v) << 9) >>> +#define CSI2DC_VPCFG_DM_DECODER8TO12 0 >>> +/* Decoder predictor 2 selection */ >>> +#define CSI2DC_VPCFG_DP2 BIT(12) >>> +/* Recommended memory storage */ >>> +#define CSI2DC_VPCFG_RMS BIT(13) >>> +/* Post adjustment */ >>> +#define CSI2DC_VPCFG_PA BIT(14) >>> + >>> +/* Video pipeline column register */ >>> +#define CSI2DC_VPCOL 0x100 >>> +/* Column number */ >>> +#define CSI2DC_VPCOL_COL(v) ((v) << 0) >>> +#define CSI2DC_VPCOL_COL_MASKGENMASK(15, 0) >>> + >>> +/* Video pipeline row register */ >>> +#define CSI2DC_VPROW 0x104 >>> +/* Row number */ >>> +#define CSI2DC_VPROW_ROW(v) ((v) << 0) >>> +#define CSI2DC_VPROW_ROW_MASKGENMASK(15, 0) >>> + >>> +/* Version register */ >>> +#define CSI2DC_VERSION
Re: [PATCH v2 3/4] media: misc: introduce microchip_csi2dc driver
On 14.08.2020 01:44, Sakari Ailus wrote: > Hi Eugen, > > Thanks for the patch. Hello Sakari, Thanks for reviewing. > > On Fri, Jul 03, 2020 at 10:44:15AM +0300, Eugen Hristev wrote: >> Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device >> that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) >> to a pixel stream that can be captured by a sensor controller. >> >> Signed-off-by: Eugen Hristev >> --- >> drivers/media/misc/Kconfig| 9 + >> drivers/media/misc/Makefile | 1 + >> drivers/media/misc/microchip_csi2dc.c | 705 ++ >> 3 files changed, 715 insertions(+) >> create mode 100644 drivers/media/misc/microchip_csi2dc.c >> >> diff --git a/drivers/media/misc/Kconfig b/drivers/media/misc/Kconfig >> index 206f39f86f46..86e892a41eba 100644 >> --- a/drivers/media/misc/Kconfig >> +++ b/drivers/media/misc/Kconfig >> @@ -8,6 +8,15 @@ menu "Miscellaneous helper chips" >> >> comment "Various helper chips" >> >> +config VIDEO_MICROCHIP_CSI2DC >> + tristate "Microchip CSI2 Demux Controller" >> + depends on VIDEO_V4L2 >> + help >> + CSI2 Demux Controller driver. CSI2DC is a helper chip >> + that converts IDI interface byte stream to a parallel pixel stream. >> + It supports various RAW formats as input. >> + Performs clock domain crossing between hardware blocks. >> + >> endmenu >> >> endif >> diff --git a/drivers/media/misc/Makefile b/drivers/media/misc/Makefile >> index f66554cd5c45..86477781b7af 100644 >> --- a/drivers/media/misc/Makefile >> +++ b/drivers/media/misc/Makefile >> @@ -1 +1,2 @@ >> # SPDX-License-Identifier: GPL-2.0 >> +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip_csi2dc.o >> diff --git a/drivers/media/misc/microchip_csi2dc.c >> b/drivers/media/misc/microchip_csi2dc.c >> new file mode 100644 >> index ..494b7c137b17 >> --- /dev/null >> +++ b/drivers/media/misc/microchip_csi2dc.c >> @@ -0,0 +1,705 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Microchip CSI2 Demux Controller (CSI2DC) driver >> + * >> + * Copyright (C) 2018-2020 Microchip Technology, Inc. >> + * >> + * Author: Eugen Hristev >> + * >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> + >> +/* Global configuration register */ >> +#define CSI2DC_GCFG 0x0 >> + >> +/* MIPI sensor pixel clock is free running */ >> +#define CSI2DC_GCFG_MIPIFRN BIT(0) >> +/* Output waveform inter-line minimum delay */ >> +#define CSI2DC_GCFG_HLC(v) ((v) << 4) >> +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) >> + >> +/* Global control register */ >> +#define CSI2DC_GCTLR 0x04 >> +#define CSI2DC_GCTLR_SWRST BIT(0) >> + >> +/* Global status register */ >> +#define CSI2DC_GS0x08 >> + >> +/* SSP interrupt status register */ >> +#define CSI2DC_SSPIS 0x28 >> +/* Pipe update register */ >> +#define CSI2DC_PU0xC0 >> +/* Video pipe attributes update */ >> +#define CSI2DC_PU_VP BIT(0) >> + >> +/* Pipe update status register */ >> +#define CSI2DC_PUS 0xC4 >> + >> +/* Video pipeline enable register */ >> +#define CSI2DC_VPE 0xF8 >> +#define CSI2DC_VPE_ENABLEBIT(0) >> + >> +/* Video pipeline configuration register */ >> +#define CSI2DC_VPCFG 0xFC >> +/* Data type */ >> +#define CSI2DC_VPCFG_DT(v) ((v) << 0) >> +#define CSI2DC_VPCFG_DT_MASK GENMASK(5, 0) >> +/* Virtual channel identifier */ >> +#define CSI2DC_VPCFG_VC(v) ((v) << 6) >> +#define CSI2DC_VPCFG_VC_MASK GENMASK(7, 6) >> +/* Decompression enable */ >> +#define CSI2DC_VPCFG_DE BIT(8) >> +/* Decoder mode */ >> +#define CSI2DC_VPCFG_DM(v) ((v) << 9) >> +#define CSI2DC_VPCFG_DM_DECODER8TO12 0 >> +/* Decoder predictor 2 selection */ >> +#define CSI2DC_VPCFG_DP2 BIT(12) >> +/* Recommended memory storage */ >> +#define CSI2DC_VPCFG_RMS BIT(13) >> +/* Post adjustment */ >> +#define CSI2DC_VPCFG_PA BIT(14) >> + >> +/* Video pipeline column register */ >> +#define CSI2DC_VPCOL 0x100 >> +/* Column number */ >> +#define CSI2DC_VPCOL_COL(v) ((v) << 0) >> +#define CSI2DC_VPCOL_COL_MASKGENMASK(15, 0) >> + >> +/* Video pipeline row register */ >> +#define CSI2DC_VPROW 0x104 >> +/* Row number */ >> +#define CSI2DC_VPROW_ROW(v) ((v) << 0) >> +#define CSI2DC_VPROW_ROW_MASKGENMASK(15, 0) >> + >> +/* Version register */ >> +#define CSI2DC_VERSION 0x1FC >> + >> +/* register read/write helpers */ >> +#define csi2dc_readl(st, reg)readl_relaxed((st)->base + >> (reg)) >> +#define csi2dc_writel(st, reg, val)
Re: [PATCH v2 1/4] dt-bindings: media: csi2dc: add bindings for microchip csi2dc
On 03.07.2020 10:44, Eugen Hristev wrote: > Add bindings documentation for microchip CSI2 Demultiplexer controller. > > CSI2DC is a demultiplexer from Synopsys IDI interface specification to > parallel interface connection or direct memory access. > > Signed-off-by: Eugen Hristev > --- > Changes in v2: > - fixed warnings reported by dt_binding_check > > > .../bindings/media/microchip,csi2dc.yaml | 185 ++ > 1 file changed, 185 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/microchip,csi2dc.yaml > > diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml > b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml > new file mode 100644 > index ..b7c46f7ad2a4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml > @@ -0,0 +1,185 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Microchip CSI2 Demux Controller (CSI2DC) > + > +maintainers: > + - Eugen Hristev > + > +description: > + CSI2DC - Camera Serial Interface 2 Demux Controller > + > + CSI2DC is a hardware block that receives incoming data from an IDI > interface > + and filters packets based on their data type and virtual channel > identifier, > + then converts the byte stream into a cross clock domain to a pixel stream > + to a parallel interface that can be read by a sensor controller. > + > + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe > + is connected to a sensor controller and the data pipe is accessible > + as a DMA slave port to a DMA controller. > + > + CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit > + IDI interface. The connected endpoint must be a IDI interface compatible > + device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface > + connection as sink pad. Hello Sakari, Could you have a look at my binding, especially this paragraph above. This controller that we have requires the Synopsys IDI interface as source pad. As this interface is not yet in kernel, do you think it's fine to mention it here ? Or how should I proceed ? In my tests and the example at the end of this binding, I just use the port and endpoints without any specific properties. The CSI2DC will actually wait an async completion (with a notifier) for that device to be registered, and then use it as a subdevice. In turn, CSI2DC registers a subdev for the next port in pipeline, towards the upper level ( the image sensor controller) However, the connection with the subdevice in this case will likely default to parallel, and not be at all in any of the cases in the video-interfaces.txt : - bus-type: data bus type. Possible values are: 1 - MIPI CSI-2 C-PHY 2 - MIPI CSI1 3 - CCP2 4 - MIPI CSI-2 D-PHY 5 - Parallel 6 - Bt.656 as this interface type is actually Synopsys IDI. Do you think this is fine ? Thanks, Eugen > + It should contain one 'port' child node with one child 'endpoint' node. > + This node should always have the 'reg' property as 0, being the first child > + node. > + For media entity and endpoints please refer to the bindings defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt. > + For Synopsys IDI interface please refer to > + Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt > + > + CSI2DC supports one 'port' node as sink pad with parallel interface. This > is > + called video pipe. > + The reg property inside this 'port' node must have the 'reg' property as 1, > + being the second child node. > + This node must have one 'endpoint', and this 'endpoint' is related to the > + virtual channel identifier. > + The 'reg' property inside this 'endpoint' represents the CSI2 virtual > channel > + identifier. > + This 'endpoint' can then be used as a source pad for another controller > + (next in pipeline). > + Please refer to the bindings defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt. > + > + CSI2DC must have two clocks to function correctly. One clock is the > + peripheral clock for the inside functionality of the hardware block. > + This is named 'pclk'. The second clock must be the cross domain clock, > + in which CSI2DC will perform clock crossing. This clock must be fed > + by the next controller in pipeline, which usually is a sensor controller. > + Normally this clock should be given by this sensor controller who > + is also a clock source. This clock is named 'scck', sensor controller > clock. > + > + CSI2DC also supports direct access to the data through AHB, via DMA > channel, > + called data pipe. > + Because of this, the sink 'port' child node (second) is not mandatory. > + If the sink 'port' child node is missing, only data pipe is available. > + >
Re: [PATCH v2 1/4] dt-bindings: media: csi2dc: add bindings for microchip csi2dc
On 14.07.2020 05:55, Rob Herring wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, Jul 03, 2020 at 10:44:13AM +0300, Eugen Hristev wrote: >> Add bindings documentation for microchip CSI2 Demultiplexer controller. >> >> CSI2DC is a demultiplexer from Synopsys IDI interface specification to >> parallel interface connection or direct memory access. >> >> Signed-off-by: Eugen Hristev >> --- >> Changes in v2: >> - fixed warnings reported by dt_binding_check >> >> >> .../bindings/media/microchip,csi2dc.yaml | 185 ++ >> 1 file changed, 185 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> >> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> new file mode 100644 >> index ..b7c46f7ad2a4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml >> @@ -0,0 +1,185 @@ >> +# SPDX-License-Identifier: GPL-2.0-only > > New bindings should be: > > (GPL-2.0-only OR BSD-2-Clause) > >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Microchip CSI2 Demux Controller (CSI2DC) >> + >> +maintainers: >> + - Eugen Hristev >> + >> +description: >> + CSI2DC - Camera Serial Interface 2 Demux Controller >> + >> + CSI2DC is a hardware block that receives incoming data from an IDI >> interface >> + and filters packets based on their data type and virtual channel >> identifier, >> + then converts the byte stream into a cross clock domain to a pixel stream >> + to a parallel interface that can be read by a sensor controller. >> + >> + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe >> + is connected to a sensor controller and the data pipe is accessible >> + as a DMA slave port to a DMA controller. >> + >> + CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit >> + IDI interface. The connected endpoint must be a IDI interface compatible >> + device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface >> + connection as sink pad. >> + It should contain one 'port' child node with one child 'endpoint' node. >> + This node should always have the 'reg' property as 0, being the first >> child >> + node. > > This information should be expressed as a schema. Hello Rob, Do you mean that I should add these explanations inside the schema properties description ? Or I should enforce these in some other way ? The schema already includes what is written here (for example, const reg 0 for the child node, etc.) Or maybe you wanted to tell me something else ? Thanks, Eugen > >> + For media entity and endpoints please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. >> + For Synopsys IDI interface please refer to >> + Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt >> + > >> + CSI2DC supports one 'port' node as sink pad with parallel interface. This >> is >> + called video pipe. >> + The reg property inside this 'port' node must have the 'reg' property as >> 1, >> + being the second child node. >> + This node must have one 'endpoint', and this 'endpoint' is related to the >> + virtual channel identifier. >> + The 'reg' property inside this 'endpoint' represents the CSI2 virtual >> channel >> + identifier. >> + This 'endpoint' can then be used as a source pad for another controller >> + (next in pipeline). >> + Please refer to the bindings defined in >> + Documentation/devicetree/bindings/media/video-interfaces.txt. > > And all this. > >> + >> + CSI2DC must have two clocks to function correctly. One clock is the >> + peripheral clock for the inside functionality of the hardware block. >> + This is named 'pclk'. The second clock must be the cross domain clock, >> + in which CSI2DC will perform clock crossing. This clock must be fed >> + by the next controller in pipeline, which usually is a sensor controller. >> + Normally this clock should be given by this sensor controller who >> + is also a clock source. This clock is named 'scck', sensor controller >> clock. > > Better to be part of 'clocks'. > >> + >> + CSI2DC also supports direct access to the data through AHB, via DMA >> channel, >> + called data pipe. >> + Because of this, the sink 'port' child node (second) is not mandatory. >> + If the sink 'port' child node is missing, only data pipe is available. >> + >> +properties: >> + compatible: >> +const: microchip,sama7g5-csi2dc >> + >> + reg: >> +description: >> + Physical base address and length of the registers set for the device. > > That is every 'reg' prop. Drop. > >> +maxItems: 1 >> + >> + clocks: >> +maxItems: 2 >> + >> + clock-names: >> +
Re: [PATCH v2 1/4] dt-bindings: media: csi2dc: add bindings for microchip csi2dc
On 14.08.2020 01:46, Sakari Ailus wrote: > Hi Eugen, > > On Fri, Jul 03, 2020 at 10:44:13AM +0300, Eugen Hristev wrote: >> Add bindings documentation for microchip CSI2 Demultiplexer controller. > > ... > >> + port@1: >> +type: object >> +description: >> + Output port node, single endpoint, describing the output pad. >> + >> +properties: >> + '#address-cells': >> +const: 1 >> + >> + '#size-cells': >> +const: 0 >> + >> + reg: >> +const: 1 >> + >> +patternProperties: >> + "^endpoint@[0-9a-f]$": >> +type: object >> + >> +properties: >> + reg: >> +enum: [0, 1, 2, 3] >> +description: virtual channel for the endpoint > > Unless you need this right now I'd just hard code this to zero in the > driver. You can't have more endpoints for active devices anyway, can you? Hello Sakari, You are right, but, the virtual ID must be written in hardware registers. So I can take the virtual ID from this property. Otherwise, if I hardcode this in the driver, another virtual ID would be impossible to use without changing the driver. And if the binding is accepted without this property, it will be 'set in stone' and difficult to change afterwards. What do you think ? Eugen > > -- > Sakari Ailus >
Re: [PATCH v2 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
On 17.06.2020 16:52, Ardelean, Alexandru wrote:
> On Wed, 2020-06-17 at 13:37 +, eugen.hris...@microchip.com wrote:
>> [External]
>>
>> On 02.06.2020 11:54, Jonathan Cameron wrote:
>>> On Tue, 2 Jun 2020 07:50:23 +
>>> "Ardelean, Alexandru" wrote:
>>>
On Sun, 2020-05-31 at 16:40 +0100, Jonathan Cameron wrote:
> On Mon, 25 May 2020 14:38:55 +0300
> Alexandru Ardelean wrote:
>
>> From: Lars-Peter Clausen
>>
>> This patch should be squashed into the first one, as the first one is
>> breaking the build (intentionally) to make the IIO core files easier
>> to
>> review.
>>
>> Signed-off-by: Lars-Peter Clausen
>> Signed-off-by: Alexandru Ardelean
>> ---
>
> Friend poke. Version log?
Version log is in the first patch.
I was wondering if I omitted it.
Seems, this time I didn't. But I admit, it probably would have been better
here.
>>> Ah fair enough. That works fine if there is a cover letter but not
>>> so much just putting things in the first patch!
> Other than the wistful comment below (which I'm not expecting you to
> do anything about btw!) whole series looks good to me.
>
> These are obviously no functional changes (I think) so it's only really
> patch 2 that
> could do with more eyes and acks.
>
> Far as I can tell that case is fine as well because of the protections
> on being in the right mode, but more eyes on that would be great.
>
> So assuming that's fine, what commit message do you want me to use for
> the fused single patch?
Commit message-wise: I think the message in the first commit would be
mostly sufficient.
No idea what other description would be needed.
So, maybe something like:
--
All devices using a triggered buffer need to attach and detach the trigger
to the device in order to properly work. Instead of doing this in each and
every driver by hand move this into the core.
At this point in time, all drivers should have been resolved to
attach/detach the poll-function in the same order.
This patch removes all explicit calls of iio_triggered_buffer_postenable()
& iio_triggered_buffer_predisable() in all drivers, since the core handles
now the pollfunc attach/detach.
The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's
not obvious that removing the hooks doesn't break anything**
--
>>>
>>> Looks good.
>>>
** for the comment about 'at91-sama5d2_adc', we really do need to get some
testing; otherwise this risks breaking it.
>>
>> Hi,
>>
>> I can test it, do we have any patchwork so I can easily download the
>> patches ?
>> I have issues when applying them.
>
> Is this good?
>
> https://patchwork.kernel.org/patch/11568743/
> Series:
> https://patchwork.kernel.org/project/linux-iio/list/?series=293141
>
> Many thanks
> Alex
On at91-sama5d2-adc driver, sama5d2-xplained board,
Tested-by: Eugen Hristev
I applied all three patches and tested together with the other patch on
sama5d2-adc driver.
It looks to be working fine. If I discover something later, I will let
you know.
Thanks
>
>>
>> Thanks !
>>
>>> Agreed.
>>>
> Thanks,
>
> Jonathan
>
>>static const struct iio_trigger_ops atlas_interrupt_trigger_ops = {
>> diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c
>> b/drivers/iio/dummy/iio_simple_dummy_buffer.c
>> index 17606eca42b4..8e13c53d4360 100644
>> --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c
>> +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c
>> @@ -99,20 +99,6 @@ static irqreturn_t iio_simple_dummy_trigger_h(int
>> irq, void *p)
>>}
>>
>>static const struct iio_buffer_setup_ops
>> iio_simple_dummy_buffer_setup_ops = {
>> - /*
>> - * iio_triggered_buffer_postenable:
>> - * Generic function that simply attaches the pollfunc to the
>> trigger.
>> - * Replace this to mess with hardware state before we attach the
>> - * trigger.
>> - */
>> - .postenable = _triggered_buffer_postenable,
>> - /*
>> - * iio_triggered_buffer_predisable:
>> - * Generic function that simple detaches the pollfunc from the
>> trigger.
>> - * Replace this to put hardware state back again after the trigger
>> is
>> - * detached but before userspace knows we have disabled the ring.
>> - */
>> - .predisable = _triggered_buffer_predisable,
>>};
>>
> Hmm. Guess we should probably 'invent' a reason to illustrate the bufer
> ops in the dummy example. Anyone feeling creative?
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
Re: [PATCH] iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper
On 17.06.2020 17:02, Ardelean, Alexandru wrote:
> On Wed, 2020-06-17 at 13:25 +, eugen.hris...@microchip.com wrote:
>> On 31.05.2020 17:39, Jonathan Cameron wrote:
>>
>>> On Mon, 25 May 2020 13:53:41 +0300
>>> Alexandru Ardelean wrote:
>>>
We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.
Hiding the implementation of iio_priv_to_dev() implies that some fast-
paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework, as the iio_dev
struct will keep a reference to the private information.
For this driver, not using iio_priv_to_dev(), means reworking some paths
to
pass the iio device and using iio_priv() to access the private
information,
and also keeping a reference to the iio device for some quirky paths.
One [quirky] path is the at91_adc_workq_handler() which requires the IIO
device & the state struct to push to buffers.
Since this requires the back-ref to the IIO device, the
at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The
information required in this function is mostly for debugging purposes.
Replacing it with a reference to the IIO device would have been a slightly
bigger change, which may not be worth it (for just the debugging purpose
and given that we need the back-ref to the IIO device anyway).
>>>
>>> That workq is indeed quirky. This looks fine to me in general. I'll
>>> want an appropriate ack from the at91 side of things if possible so
>>> let's leave this on the list for a while longer.
>>
>> Hi,
>>
>> I am available to test this patch,
>> Can you tell me on which branch to apply it. On 5.8-rc1 it fails for me
>> (or maybe it needs rebasing ?)
>>
>
> Hmm, weird.
> I rebased the patches on Jonathan's iio/testing.
> It seemed to work.
> https://github.com/commodo/linux/commits/iio-priv-to-dev
>
> As for which branch to test/apply. Not sure.
> Maybe Jonathan's iio/testing as base?
> Looks like it's based on 5.8.
>
Tested-by: Eugen Hristev
I have tested the major features of the driver (including the resistive
touch) and it looks to be working fine.
I did not fully understand the quirkyness of the workq . Something you
want to change to that ?
>
>> Eugen
>>
>>> Poke me if no action in a few weeks.
>>>
>>> Thanks,
>>>
>>> Jonathan
>>>
Signed-off-by: Alexandru Ardelean
---
drivers/iio/adc/at91-sama5d2_adc.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-
sama5d2_adc.c
index 9abbbdcc7420..7bce1830 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -402,6 +402,7 @@ struct at91_adc_state {
wait_queue_head_t wq_data_available;
struct at91_adc_dma dma_st;
struct at91_adc_touch touch_st;
+ struct iio_dev *indio_dev;
u16 buffer[AT91_BUFFER_MAX_HWORDS];
/*
* lock to prevent concurrent 'single conversion' requests through
@@ -642,13 +643,13 @@ static u16 at91_adc_touch_pos(struct at91_adc_state
*st, int reg)
/* first half of register is the x or y, second half is the scale
*/
val = at91_adc_readl(st, reg);
if (!val)
- dev_dbg(_priv_to_dev(st)->dev, "pos is 0\n");
+ dev_dbg(>indio_dev->dev, "pos is 0\n");
pos = val & AT91_SAMA5D2_XYZ_MASK;
result = (pos << AT91_SAMA5D2_MAX_POS_BITS) - pos;
scale = (val >> 16) & AT91_SAMA5D2_XYZ_MASK;
if (scale == 0) {
- dev_err(_priv_to_dev(st)->dev, "scale is 0\n");
+ dev_err(>indio_dev->dev, "scale is 0\n");
return 0;
}
result /= scale;
@@ -1204,9 +1205,9 @@ static unsigned at91_adc_startup_time(unsigned
startup_time_min,
return i;
}
-static void at91_adc_setup_samp_freq(struct at91_adc_state *st, unsigned
freq)
+static void at91_adc_setup_samp_freq(struct iio_dev *indio_dev, unsigned
freq)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(st);
+ struct at91_adc_state *st = iio_priv(indio_dev);
unsigned f_per, prescal, startup, mr;
f_per = clk_get_rate(st->per_clk);
@@ -1275,9 +1276,9 @@ static void at91_adc_pen_detect_interrupt(struct
at91_adc_state *st)
Re: [PATCH v2 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
On 02.06.2020 11:54, Jonathan Cameron wrote:
> On Tue, 2 Jun 2020 07:50:23 +
> "Ardelean, Alexandru" wrote:
>
>> On Sun, 2020-05-31 at 16:40 +0100, Jonathan Cameron wrote:
>>> On Mon, 25 May 2020 14:38:55 +0300
>>> Alexandru Ardelean wrote:
>>>
From: Lars-Peter Clausen
This patch should be squashed into the first one, as the first one is
breaking the build (intentionally) to make the IIO core files easier to
review.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Alexandru Ardelean
---
>>>
>>> Friend poke. Version log?
>>
>> Version log is in the first patch.
>> I was wondering if I omitted it.
>> Seems, this time I didn't. But I admit, it probably would have been better
>> here.
> Ah fair enough. That works fine if there is a cover letter but not
> so much just putting things in the first patch!
>>
>>>
>>> Other than the wistful comment below (which I'm not expecting you to
>>> do anything about btw!) whole series looks good to me.
>>>
>>> These are obviously no functional changes (I think) so it's only really
>>> patch 2 that
>>> could do with more eyes and acks.
>>>
>>> Far as I can tell that case is fine as well because of the protections
>>> on being in the right mode, but more eyes on that would be great.
>>>
>>> So assuming that's fine, what commit message do you want me to use for
>>> the fused single patch?
>>
>> Commit message-wise: I think the message in the first commit would be
>> mostly sufficient.
>> No idea what other description would be needed.
>>
>> So, maybe something like:
>>
>> --
>> All devices using a triggered buffer need to attach and detach the trigger
>> to the device in order to properly work. Instead of doing this in each and
>> every driver by hand move this into the core.
>>
>> At this point in time, all drivers should have been resolved to
>> attach/detach the poll-function in the same order.
>>
>> This patch removes all explicit calls of iio_triggered_buffer_postenable()
>> & iio_triggered_buffer_predisable() in all drivers, since the core handles
>> now the pollfunc attach/detach.
>>
>> The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's
>> not obvious that removing the hooks doesn't break anything**
>> --
>>
>
> Looks good.
>
>> ** for the comment about 'at91-sama5d2_adc', we really do need to get some
>> testing; otherwise this risks breaking it.
>
Hi,
I can test it, do we have any patchwork so I can easily download the
patches ?
I have issues when applying them.
Thanks !
> Agreed.
>
>>
>>
>>>
>>> Thanks,
>>>
>>> Jonathan
>>>
static const struct iio_trigger_ops atlas_interrupt_trigger_ops = {
diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c
b/drivers/iio/dummy/iio_simple_dummy_buffer.c
index 17606eca42b4..8e13c53d4360 100644
--- a/drivers/iio/dummy/iio_simple_dummy_buffer.c
+++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c
@@ -99,20 +99,6 @@ static irqreturn_t iio_simple_dummy_trigger_h(int
irq, void *p)
}
static const struct iio_buffer_setup_ops
iio_simple_dummy_buffer_setup_ops = {
- /*
- * iio_triggered_buffer_postenable:
- * Generic function that simply attaches the pollfunc to the
trigger.
- * Replace this to mess with hardware state before we attach the
- * trigger.
- */
- .postenable = _triggered_buffer_postenable,
- /*
- * iio_triggered_buffer_predisable:
- * Generic function that simple detaches the pollfunc from the
trigger.
- * Replace this to put hardware state back again after the trigger
is
- * detached but before userspace knows we have disabled the ring.
- */
- .predisable = _triggered_buffer_predisable,
};
>>> Hmm. Guess we should probably 'invent' a reason to illustrate the bufer
>>> ops in the dummy example. Anyone feeling creative?
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
Re: [PATCH] iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper
On 31.05.2020 17:39, Jonathan Cameron wrote:
> On Mon, 25 May 2020 13:53:41 +0300
> Alexandru Ardelean wrote:
>
>> We may want to get rid of the iio_priv_to_dev() helper. The reason is that
>> we will hide some of the members of the iio_dev structure (to prevent
>> drivers from accessing them directly), and that will also mean hiding the
>> implementation of the iio_priv_to_dev() helper inside the IIO core.
>>
>> Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
>> may not be fast anymore, so a general idea is to try to get rid of the
>> iio_priv_to_dev() altogether.
>> The iio_priv() helper won't be affected by the rework, as the iio_dev
>> struct will keep a reference to the private information.
>>
>> For this driver, not using iio_priv_to_dev(), means reworking some paths to
>> pass the iio device and using iio_priv() to access the private information,
>> and also keeping a reference to the iio device for some quirky paths.
>>
>> One [quirky] path is the at91_adc_workq_handler() which requires the IIO
>> device & the state struct to push to buffers.
>> Since this requires the back-ref to the IIO device, the
>> at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The
>> information required in this function is mostly for debugging purposes.
>> Replacing it with a reference to the IIO device would have been a slightly
>> bigger change, which may not be worth it (for just the debugging purpose
>> and given that we need the back-ref to the IIO device anyway).
>
> That workq is indeed quirky. This looks fine to me in general. I'll
> want an appropriate ack from the at91 side of things if possible so
> let's leave this on the list for a while longer.
Hi,
I am available to test this patch,
Can you tell me on which branch to apply it. On 5.8-rc1 it fails for me
(or maybe it needs rebasing ?)
Eugen
>
> Poke me if no action in a few weeks.
>
> Thanks,
>
> Jonathan
>
>>
>> Signed-off-by: Alexandru Ardelean
>> ---
>> drivers/iio/adc/at91-sama5d2_adc.c | 30 +-
>> 1 file changed, 17 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c
>> b/drivers/iio/adc/at91-sama5d2_adc.c
>> index 9abbbdcc7420..7bce1830 100644
>> --- a/drivers/iio/adc/at91-sama5d2_adc.c
>> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
>> @@ -402,6 +402,7 @@ struct at91_adc_state {
>>wait_queue_head_t wq_data_available;
>>struct at91_adc_dma dma_st;
>>struct at91_adc_touch touch_st;
>> + struct iio_dev *indio_dev;
>>u16 buffer[AT91_BUFFER_MAX_HWORDS];
>>/*
>> * lock to prevent concurrent 'single conversion' requests through
>> @@ -642,13 +643,13 @@ static u16 at91_adc_touch_pos(struct at91_adc_state
>> *st, int reg)
>>/* first half of register is the x or y, second half is the scale */
>>val = at91_adc_readl(st, reg);
>>if (!val)
>> - dev_dbg(_priv_to_dev(st)->dev, "pos is 0\n");
>> + dev_dbg(>indio_dev->dev, "pos is 0\n");
>>
>>pos = val & AT91_SAMA5D2_XYZ_MASK;
>>result = (pos << AT91_SAMA5D2_MAX_POS_BITS) - pos;
>>scale = (val >> 16) & AT91_SAMA5D2_XYZ_MASK;
>>if (scale == 0) {
>> - dev_err(_priv_to_dev(st)->dev, "scale is 0\n");
>> + dev_err(>indio_dev->dev, "scale is 0\n");
>>return 0;
>>}
>>result /= scale;
>> @@ -1204,9 +1205,9 @@ static unsigned at91_adc_startup_time(unsigned
>> startup_time_min,
>>return i;
>> }
>>
>> -static void at91_adc_setup_samp_freq(struct at91_adc_state *st, unsigned
>> freq)
>> +static void at91_adc_setup_samp_freq(struct iio_dev *indio_dev, unsigned
>> freq)
>> {
>> - struct iio_dev *indio_dev = iio_priv_to_dev(st);
>> + struct at91_adc_state *st = iio_priv(indio_dev);
>>unsigned f_per, prescal, startup, mr;
>>
>>f_per = clk_get_rate(st->per_clk);
>> @@ -1275,9 +1276,9 @@ static void at91_adc_pen_detect_interrupt(struct
>> at91_adc_state *st)
>>st->touch_st.touching = true;
>> }
>>
>> -static void at91_adc_no_pen_detect_interrupt(struct at91_adc_state *st)
>> +static void at91_adc_no_pen_detect_interrupt(struct iio_dev *indio_dev)
>> {
>> - struct iio_dev *indio_dev = iio_priv_to_dev(st);
>> + struct at91_adc_state *st = iio_priv(indio_dev);
>>
>>at91_adc_writel(st, AT91_SAMA5D2_TRGR,
>>AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER);
>> @@ -1297,7 +1298,7 @@ static void at91_adc_workq_handler(struct work_struct
>> *workq)
>>struct at91_adc_touch, workq);
>>struct at91_adc_state *st = container_of(touch_st,
>>struct at91_adc_state, touch_st);
>> - struct iio_dev *indio_dev = iio_priv_to_dev(st);
>> + struct iio_dev *indio_dev = st->indio_dev;
>>
>>
Re: drivers/media/platform/atmel/atmel-sama5d2-isc.c:323:34: warning: unused variable 'atmel_isc_of_match'
On 12.06.2020 09:02, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: b791d1bdf9212d944d749a5c7ff6febdba241771
> commit: 0a0e265515db7619d0da9331d74245d02c741f07 media: atmel: atmel-isc:
> split driver into driver base and isc
> date: 12 months ago
> config: x86_64-randconfig-a012-20200612 (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
> 3b43f006294971b8049d4807110032169780e5b8)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> git checkout 0a0e265515db7619d0da9331d74245d02c741f07
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
> ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
Sent a patch to address this warning
Thanks
>
> All warnings (new ones prefixed by >>, old ones prefixed by <<):
>
>>> drivers/media/platform/atmel/atmel-sama5d2-isc.c:323:34: warning: unused
>>> variable 'atmel_isc_of_match' [-Wunused-const-variable]
> static const struct of_device_id atmel_isc_of_match[] = {
> ^
> 1 warning generated.
>
> vim +/atmel_isc_of_match +323 drivers/media/platform/atmel/atmel-sama5d2-isc.c
>
> 322
> > 323 static const struct of_device_id atmel_isc_of_match[] = {
> 324 { .compatible = "atmel,sama5d2-isc" },
> 325 { }
> 326 };
> 327 MODULE_DEVICE_TABLE(of, atmel_isc_of_match);
> 328
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
>
Re: [RFC PATCH] iio: __iio_update_buffers: Update mode before preenable/after postdisable
On 04.05.2020 15:27, Eugen Hristev - M18282 wrote:
> On 30.04.2020 11:42, Eugen Hristev - M18282 wrote:
>> On 30.04.2020 11:24, Alexandru Ardelean wrote:
>>> From: Lars-Peter Clausen
>>>
>>> It is clear that we transition to INDIO_DIRECT_MODE when disabling the
>>> buffer(s) and it is also clear that we transition from INDIO_DIRECT_MODE
>>> when enabling the buffer(s). So leaving the currentmode field
>>> INDIO_DIRECT_MODE until after the preenable() callback and updating it to
>>> INDIO_DIRECT_MODE before the postdisable() callback doesn't add additional
>>> value. On the other hand some drivers will need to perform different
>>> actions depending on which mode the device is going to operate in/was
>>> operating in.
>>>
>>> Moving the update of currentmode before preenable() and after postdisable()
>>> enables us to have drivers which perform mode dependent actions in those
>>> callbacks.
>>>
>>> Signed-off-by: Lars-Peter Clausen
>>> Signed-off-by: Alexandru Ardelean
>>> ---
>>>
>>> This patch is also a V2 of this older patch from a while ago:
>>>
>>> https://lore.kernel.org/linux-iio/1431525891-19285-5-git-send-email-l...@metafoo.de/
>>>
>>> However, in this recent context, it comes to fix this:
>>>
>>> https://lore.kernel.org/linux-iio/b9ab676489de3575984dac5610fcf05fd8742a38.ca...@analog.com/T/#mc09284c8f79250b92a52fd5b8d1f541d1c02c0c0
>>>
>>> At this point, I don't have a clear idea if this approach is good or
>>> not; since the motivation is to fix the at91 adc.
>>> Hence the RFC.
>>>
>>> Some excerpt from the AT91 discussion:
>>> ---
>>> I decided to do a bit of shell magic for this:
>>>
>>> get_files() {
>>> git grep -w iio_buffer_setup_ops | grep drivers | cut -d: -f1 | sort | uniq
>>> }
>>>
>>> for file in $(get_files) ; do
>>>if grep -q currentmode $file ; then
>>>echo $file
>>>fi
>>> done
>>>
>>> It finds 4 drivers.
>>> Though, `get_files()` will return 56 files.
>>>
>>> drivers/iio/accel/bmc150-accel-core.c
>>> drivers/iio/adc/at91-sama5d2_adc.c
>>> drivers/iio/adc/stm32-dfsdm-adc.c
>>> drivers/iio/magnetometer/rm3100-core.c
>>>
>>> The rm3100 driver doesn't do any checks in the setup_ops for 'currentmode'
>>> as
>>> far as I could see.
>>>
>>> So, Lars' patch could work nicely to fix this current case and not break
>>> others.
>>>
>>> Semantically though, it would sound nicer to have a 'nextmode' parameter
>>> somewhere; maybe on the setup_ops(indio_dev, nextmode)?
>>> Though, only those 3 drivers would really ever use it; so doing it like that
>>> sounds like overkill.
>>>
>>> So, we're left with Lars' patch or we could add an 'indio_dev->nextmode'
>>> field,
>>> that may be used in just these 3 drivers [which again: sounds overkill at
>>> this
>>> point in time].
>>>
>>> Alternatively, this 'indio_dev->currentmode' could be removed from all
>>> these 3
>>> drivers somehow. But that needs testing and a thorough understanding of all
>>> 3
>>> drivers and what they're doing, to do properly.
>>> ---
>>
>> Hi Alex,
>>
>> Thanks for finding this. I will test this with the at91-sama5d2_adc
>> driver on Jonathan's testing branch. I will let you know of the results.
>>
>> Eugen
>
> Hi,
>
> For sama5d2-xplained, hw trigger testing, at91-sama5d2_adc driver,
> Tested-by: Eugen Hristev
>
> I did not get my hands on the touchscreen yet, but hopefully soon.
>
> Thanks again,
> Eugen
Hello Jonathan,
Without this patch, your current testing branch is broken for hardware
trigger for at91-sama5d2_adc (including for-5.8b tag)
You want me to create a patch that fixes that in the driver, or you will
take this patch maybe ?
Thanks !
Eugen
>>
>>>
>>> drivers/iio/industrialio-buffer.c | 8 +++-
>>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/iio/industrialio-buffer.c
>>> b/drivers/iio/industrialio-buffer.c
>>> index 30af8af8f312..efcc44b62946 100644
>>> --- a/drivers/iio/industrialio-buffer.c
>>> +++ b/drivers/iio/industrialio-buffer.c
>>> @@ -989,6 +989,7 @@ static int iio_enable_buffers(struct iio_dev *indio_dev,
>>>indio_dev->active_scan_mask = config->scan_mask;
>>>indio_dev->scan_timestamp = config->scan_timestamp;
>>>indio_dev->scan_bytes = config->scan_bytes;
>>> + indio_dev->currentmode = config->mode;
>>>
>>>iio_update_demux(indio_dev);
>>>
>>> @@ -1024,8 +1025,6 @@ static int iio_enable_buffers(struct iio_dev
>>> *indio_dev,
>>>goto err_disable_buffers;
>>>}
>>>
>>> - indio_dev->currentmode = config->mode;
>>> -
>>>if (indio_dev->setup_ops->postenable) {
>>>ret = indio_dev->setup_ops->postenable(indio_dev);
>>>if (ret) {
>>> @@ -1042,10 +1041,10 @@ static int iio_enable_buffers(struct iio_dev
>>> *indio_dev,
>>>
Re: [RFC PATCH] iio: __iio_update_buffers: Update mode before preenable/after postdisable
On 30.04.2020 11:42, Eugen Hristev - M18282 wrote:
> On 30.04.2020 11:24, Alexandru Ardelean wrote:
>> From: Lars-Peter Clausen
>>
>> It is clear that we transition to INDIO_DIRECT_MODE when disabling the
>> buffer(s) and it is also clear that we transition from INDIO_DIRECT_MODE
>> when enabling the buffer(s). So leaving the currentmode field
>> INDIO_DIRECT_MODE until after the preenable() callback and updating it to
>> INDIO_DIRECT_MODE before the postdisable() callback doesn't add additional
>> value. On the other hand some drivers will need to perform different
>> actions depending on which mode the device is going to operate in/was
>> operating in.
>>
>> Moving the update of currentmode before preenable() and after postdisable()
>> enables us to have drivers which perform mode dependent actions in those
>> callbacks.
>>
>> Signed-off-by: Lars-Peter Clausen
>> Signed-off-by: Alexandru Ardelean
>> ---
>>
>> This patch is also a V2 of this older patch from a while ago:
>>
>> https://lore.kernel.org/linux-iio/1431525891-19285-5-git-send-email-l...@metafoo.de/
>>
>> However, in this recent context, it comes to fix this:
>>
>> https://lore.kernel.org/linux-iio/b9ab676489de3575984dac5610fcf05fd8742a38.ca...@analog.com/T/#mc09284c8f79250b92a52fd5b8d1f541d1c02c0c0
>>
>> At this point, I don't have a clear idea if this approach is good or
>> not; since the motivation is to fix the at91 adc.
>> Hence the RFC.
>>
>> Some excerpt from the AT91 discussion:
>> ---
>> I decided to do a bit of shell magic for this:
>>
>> get_files() {
>> git grep -w iio_buffer_setup_ops | grep drivers | cut -d: -f1 | sort | uniq
>> }
>>
>> for file in $(get_files) ; do
>> if grep -q currentmode $file ; then
>> echo $file
>> fi
>> done
>>
>> It finds 4 drivers.
>> Though, `get_files()` will return 56 files.
>>
>> drivers/iio/accel/bmc150-accel-core.c
>> drivers/iio/adc/at91-sama5d2_adc.c
>> drivers/iio/adc/stm32-dfsdm-adc.c
>> drivers/iio/magnetometer/rm3100-core.c
>>
>> The rm3100 driver doesn't do any checks in the setup_ops for 'currentmode' as
>> far as I could see.
>>
>> So, Lars' patch could work nicely to fix this current case and not break
>> others.
>>
>> Semantically though, it would sound nicer to have a 'nextmode' parameter
>> somewhere; maybe on the setup_ops(indio_dev, nextmode)?
>> Though, only those 3 drivers would really ever use it; so doing it like that
>> sounds like overkill.
>>
>> So, we're left with Lars' patch or we could add an 'indio_dev->nextmode'
>> field,
>> that may be used in just these 3 drivers [which again: sounds overkill at
>> this
>> point in time].
>>
>> Alternatively, this 'indio_dev->currentmode' could be removed from all these
>> 3
>> drivers somehow. But that needs testing and a thorough understanding of all 3
>> drivers and what they're doing, to do properly.
>> ---
>
> Hi Alex,
>
> Thanks for finding this. I will test this with the at91-sama5d2_adc
> driver on Jonathan's testing branch. I will let you know of the results.
>
> Eugen
Hi,
For sama5d2-xplained, hw trigger testing, at91-sama5d2_adc driver,
Tested-by: Eugen Hristev
I did not get my hands on the touchscreen yet, but hopefully soon.
Thanks again,
Eugen
>
>>
>>drivers/iio/industrialio-buffer.c | 8 +++-
>>1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/iio/industrialio-buffer.c
>> b/drivers/iio/industrialio-buffer.c
>> index 30af8af8f312..efcc44b62946 100644
>> --- a/drivers/iio/industrialio-buffer.c
>> +++ b/drivers/iio/industrialio-buffer.c
>> @@ -989,6 +989,7 @@ static int iio_enable_buffers(struct iio_dev *indio_dev,
>> indio_dev->active_scan_mask = config->scan_mask;
>> indio_dev->scan_timestamp = config->scan_timestamp;
>> indio_dev->scan_bytes = config->scan_bytes;
>> + indio_dev->currentmode = config->mode;
>>
>> iio_update_demux(indio_dev);
>>
>> @@ -1024,8 +1025,6 @@ static int iio_enable_buffers(struct iio_dev
>> *indio_dev,
>> goto err_disable_buffers;
>> }
>>
>> - indio_dev->currentmode = config->mode;
>> -
>> if (indio_dev->setup_ops->postenable) {
>> ret = indio_dev->setup_ops->postenable(indio_dev);
>> if (ret) {
>> @@ -1042,10 +1041,10 @@ static int iio_enable_buffers(struct iio_dev
>> *indio_dev,
>>buffer_list)
>> iio_buffer_disable(buffer, indio_dev);
>>err_run_postdisable:
>> - indio_dev->currentmode = INDIO_DIRECT_MODE;
>> if (indio_dev->setup_ops->postdisable)
>> indio_dev->setup_ops->postdisable(indio_dev);
>>err_undo_config:
>> + indio_dev->currentmode = INDIO_DIRECT_MODE;
>> indio_dev->active_scan_mask = NULL;
>>
>> return ret;
>> @@
Re: [RFC PATCH] iio: __iio_update_buffers: Update mode before preenable/after postdisable
On 30.04.2020 11:24, Alexandru Ardelean wrote:
> From: Lars-Peter Clausen
>
> It is clear that we transition to INDIO_DIRECT_MODE when disabling the
> buffer(s) and it is also clear that we transition from INDIO_DIRECT_MODE
> when enabling the buffer(s). So leaving the currentmode field
> INDIO_DIRECT_MODE until after the preenable() callback and updating it to
> INDIO_DIRECT_MODE before the postdisable() callback doesn't add additional
> value. On the other hand some drivers will need to perform different
> actions depending on which mode the device is going to operate in/was
> operating in.
>
> Moving the update of currentmode before preenable() and after postdisable()
> enables us to have drivers which perform mode dependent actions in those
> callbacks.
>
> Signed-off-by: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
> ---
>
> This patch is also a V2 of this older patch from a while ago:
>
> https://lore.kernel.org/linux-iio/1431525891-19285-5-git-send-email-l...@metafoo.de/
>
> However, in this recent context, it comes to fix this:
>
> https://lore.kernel.org/linux-iio/b9ab676489de3575984dac5610fcf05fd8742a38.ca...@analog.com/T/#mc09284c8f79250b92a52fd5b8d1f541d1c02c0c0
>
> At this point, I don't have a clear idea if this approach is good or
> not; since the motivation is to fix the at91 adc.
> Hence the RFC.
>
> Some excerpt from the AT91 discussion:
> ---
> I decided to do a bit of shell magic for this:
>
> get_files() {
> git grep -w iio_buffer_setup_ops | grep drivers | cut -d: -f1 | sort | uniq
> }
>
> for file in $(get_files) ; do
> if grep -q currentmode $file ; then
> echo $file
> fi
> done
>
> It finds 4 drivers.
> Though, `get_files()` will return 56 files.
>
> drivers/iio/accel/bmc150-accel-core.c
> drivers/iio/adc/at91-sama5d2_adc.c
> drivers/iio/adc/stm32-dfsdm-adc.c
> drivers/iio/magnetometer/rm3100-core.c
>
> The rm3100 driver doesn't do any checks in the setup_ops for 'currentmode' as
> far as I could see.
>
> So, Lars' patch could work nicely to fix this current case and not break
> others.
>
> Semantically though, it would sound nicer to have a 'nextmode' parameter
> somewhere; maybe on the setup_ops(indio_dev, nextmode)?
> Though, only those 3 drivers would really ever use it; so doing it like that
> sounds like overkill.
>
> So, we're left with Lars' patch or we could add an 'indio_dev->nextmode'
> field,
> that may be used in just these 3 drivers [which again: sounds overkill at this
> point in time].
>
> Alternatively, this 'indio_dev->currentmode' could be removed from all these 3
> drivers somehow. But that needs testing and a thorough understanding of all 3
> drivers and what they're doing, to do properly.
> ---
Hi Alex,
Thanks for finding this. I will test this with the at91-sama5d2_adc
driver on Jonathan's testing branch. I will let you know of the results.
Eugen
>
> drivers/iio/industrialio-buffer.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/industrialio-buffer.c
> b/drivers/iio/industrialio-buffer.c
> index 30af8af8f312..efcc44b62946 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -989,6 +989,7 @@ static int iio_enable_buffers(struct iio_dev *indio_dev,
> indio_dev->active_scan_mask = config->scan_mask;
> indio_dev->scan_timestamp = config->scan_timestamp;
> indio_dev->scan_bytes = config->scan_bytes;
> + indio_dev->currentmode = config->mode;
>
> iio_update_demux(indio_dev);
>
> @@ -1024,8 +1025,6 @@ static int iio_enable_buffers(struct iio_dev *indio_dev,
> goto err_disable_buffers;
> }
>
> - indio_dev->currentmode = config->mode;
> -
> if (indio_dev->setup_ops->postenable) {
> ret = indio_dev->setup_ops->postenable(indio_dev);
> if (ret) {
> @@ -1042,10 +1041,10 @@ static int iio_enable_buffers(struct iio_dev
> *indio_dev,
> buffer_list)
> iio_buffer_disable(buffer, indio_dev);
> err_run_postdisable:
> - indio_dev->currentmode = INDIO_DIRECT_MODE;
> if (indio_dev->setup_ops->postdisable)
> indio_dev->setup_ops->postdisable(indio_dev);
> err_undo_config:
> + indio_dev->currentmode = INDIO_DIRECT_MODE;
> indio_dev->active_scan_mask = NULL;
>
> return ret;
> @@ -1080,8 +1079,6 @@ static int iio_disable_buffers(struct iio_dev
> *indio_dev)
> ret = ret2;
> }
>
> - indio_dev->currentmode = INDIO_DIRECT_MODE;
> -
> if (indio_dev->setup_ops->postdisable) {
> ret2 = indio_dev->setup_ops->postdisable(indio_dev);
> if (ret2 && !ret)
> @@ -1090,6 +1087,7 @@
[PATCH v6 3/9] i2c: add support for filters optional properties
From: Eugen Hristev
i2c-digital-filter-width-ns:
This optional timing property specifies the width of the spikes on the i2c
lines (in ns) that can be filtered out by built-in digital filters which are
embedded in some i2c controllers.
i2c-analog-filter-cutoff-frequency:
This optional timing property specifies the cutoff frequency of a low-pass
analog filter built-in i2c controllers. This low pass filter is used to filter
out high frequency noise on the i2c lines. Specified in Hz.
Include these properties in the timings structure and read them as integers.
Signed-off-by: Eugen Hristev
---
Hello Wolfram,
I modified the comment as requested.
I only resent this patch.
Thanks !
Eugen
drivers/i2c/i2c-core-base.c | 6 ++
include/linux/i2c.h | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 5f6a498..6a5183c 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1656,6 +1656,12 @@ void i2c_parse_fw_timings(struct device *dev, struct
i2c_timings *t, bool use_de
t->sda_fall_ns = t->scl_fall_ns;
device_property_read_u32(dev, "i2c-sda-hold-time-ns", >sda_hold_ns);
+
+ device_property_read_u32(dev, "i2c-digital-filter-width-ns",
+>digital_filter_width_ns);
+
+ device_property_read_u32(dev, "i2c-analog-filter-cutoff-frequency",
+>analog_filter_cutoff_freq_hz);
}
EXPORT_SYMBOL_GPL(i2c_parse_fw_timings);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 1361637..aaf57d9 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -575,6 +575,10 @@ struct i2c_lock_operations {
* @scl_int_delay_ns: time IP core additionally needs to setup SCL in ns
* @sda_fall_ns: time SDA signal takes to fall in ns; t(f) in the I2C
specification
* @sda_hold_ns: time IP core additionally needs to hold SDA in ns
+ * @digital_filter_width_ns: width in ns of spikes on i2c lines that the IP
core
+ * digital filter can filter out
+ * @analog_filter_cutoff_freq_hz: threshold frequency for the low pass IP core
+ * analog filter
*/
struct i2c_timings {
u32 bus_freq_hz;
@@ -583,6 +587,8 @@ struct i2c_timings {
u32 scl_int_delay_ns;
u32 sda_fall_ns;
u32 sda_hold_ns;
+ u32 digital_filter_width_ns;
+ u32 analog_filter_cutoff_freq_hz;
};
/**
--
2.7.4
Re: [PATCH v5 0/9] i2c: add support for filters
On 21.10.2019 18:23, Peter Rosin wrote: > > On 2019-10-21 16:05, Wolfram Sang wrote: >> On Mon, Oct 07, 2019 at 07:53:21AM +, eugen.hris...@microchip.com wrote: >>> >>> >>> On 11.09.2019 11:24, Eugen Hristev - M18282 wrote: From: Eugen Hristev Hello, This series adds support for analog and digital filters for i2c controllers This series is based on the series: [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs and later [PATCH v4 0/9] i2c: add support for filters and enhanced to add the bindings for all controllers plus an extra bindings for the width of the spikes in nanoseconds (digital filters) and cut-off frequency (analog filters) First, bindings are created for 'i2c-analog-filter' 'i2c-digital-filter' 'i2c-digital-filter-width-ns' 'i2c-analog-filter-cutoff-frequency' The support is added in the i2c core to retrieve filter width/cutoff frequency and add it to the timings structure. Next, the at91 driver is enhanced for supporting digital filter, advanced digital filter (with selectable spike width) and the analog filter. Finally the device tree for two boards are modified to make use of the new properties. This series is the result of the comments on the ML in the direction requested: to make the bindings globally available for i2c drivers. Changes in v5: - renamed i2c-filter-width-ns to i2c-digital-filter-width-ns as this is applicable only to digital filter - created new binding i2c-digital-filter-width-ns for analog filters. >>> >>> Hello Wolfram and Peter, >>> >>> Are you happy with the changes in this version? I haven't heard from you >>> since this latest update. >>> I am interested to know if anymore changes are required or maybe we can >>> move further with this support. >> >> So, I had a look now and I am happy. I will give Peter one more day to >> comment, otherwise I'll apply it tomorrow. > > I had another read-through and only found one nit which is in a separate > message. You can add > > Reviewed-by: Peter Rosin > > for the whole series. Hello Peter and Wolfram, Thanks for reviewing. Send another version of the patch with the nit ? Or how would you like to proceed ? Thanks, Eugen > > Cheers, > Peter > >> Thanks for your patience and keeping at it! >> > > >
[PATCH v2 2/2] watchdog: sama5d4_wdt: addition of sam9x60 compatible watchdog
From: Eugen Hristev
Add support for SAM9X60 WDT into sama5d4_wdt.
This means that this driver will have a platform data that will
hold differences.
Added definitions of different bits.
The ops functions will differentiate between the two hardware blocks.
Signed-off-by: Eugen Hristev
---
Hello,
This is a rework of the separate sam9x60 watchdog driver into a single driver
that supports both hardware blocks (sam9x60 and sama5d4)
This was done as suggested on the original patches on the mailing list.
Thanks,
Eugen
drivers/watchdog/at91sam9_wdt.h | 14 +
drivers/watchdog/sama5d4_wdt.c | 127 +++-
2 files changed, 112 insertions(+), 29 deletions(-)
diff --git a/drivers/watchdog/at91sam9_wdt.h b/drivers/watchdog/at91sam9_wdt.h
index 390941c..7a053fd 100644
--- a/drivers/watchdog/at91sam9_wdt.h
+++ b/drivers/watchdog/at91sam9_wdt.h
@@ -20,7 +20,10 @@
#define AT91_WDT_MR0x04/* Watchdog Mode
Register */
#defineAT91_WDT_WDV(0xfff << 0)/*
Counter Value */
#defineAT91_WDT_SET_WDV(x) ((x) & AT91_WDT_WDV)
+#defineAT91_SAM9X60_PERIODRST BIT(4) /* Period Reset
*/
+#defineAT91_SAM9X60_RPTHRSTBIT(5) /* Minimum
Restart Period */
#defineAT91_WDT_WDFIEN (1 << 12) /*
Fault Interrupt Enable */
+#defineAT91_SAM9X60_WDDIS BIT(12) /*
Disable */
#defineAT91_WDT_WDRSTEN(1 << 13) /*
Reset Processor */
#defineAT91_WDT_WDRPROC(1 << 14) /*
Timer Restart */
#defineAT91_WDT_WDDIS (1 << 15) /*
Watchdog Disable */
@@ -33,4 +36,15 @@
#defineAT91_WDT_WDUNF (1 << 0)/*
Watchdog Underflow */
#defineAT91_WDT_WDERR (1 << 1)/*
Watchdog Error */
+#define AT91_SAM9X60_VR0x08/* Watchdog
Timer Value Register */
+
+#define AT91_SAM9X60_WLR 0x0c
+#defineAT91_SAM9X60_COUNTER(0xfff << 0)/*
Watchdog Period Value */
+#defineAT91_SAM9X60_SET_COUNTER(x) ((x) &
AT91_SAM9X60_COUNTER)
+
+#define AT91_SAM9X60_IER 0x14/* Interrupt
Enable Register */
+#defineAT91_SAM9X60_PERINT BIT(0) /*
Period Interrupt Enable */
+#define AT91_SAM9X60_IDR 0x18/* Interrupt
Disable Register */
+#define AT91_SAM9X60_ISR 0x1c/* Interrupt
Status Register */
+
#endif
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index d193a60..b92afd7 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -2,7 +2,7 @@
/*
* Driver for Atmel SAMA5D4 Watchdog Timer
*
- * Copyright (C) 2015 Atmel Corporation
+ * Copyright (C) 2015-2019 Microchip Technology Inc. and its subsidiaries
*/
#include
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,11 +26,18 @@
#define WDT_SEC2TICKS(s) ((s) ? (((s) << 8) - 1) : 0)
+struct sama5d4_wdt_data {
+ const unsigned int sam9x60_support;
+};
+
struct sama5d4_wdt {
- struct watchdog_device wdd;
- void __iomem*reg_base;
- u32 mr;
- unsigned long last_ping;
+ struct watchdog_device wdd;
+ const struct sama5d4_wdt_data *data;
+ void __iomem*reg_base;
+ u32 mr;
+ u32 ir;
+ unsigned long last_ping;
+ unsigned intneed_irq:1;
};
static int wdt_timeout;
@@ -78,7 +86,12 @@ static int sama5d4_wdt_start(struct watchdog_device *wdd)
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
- wdt->mr &= ~AT91_WDT_WDDIS;
+ if (wdt->data->sam9x60_support) {
+ writel_relaxed(wdt->ir, wdt->reg_base + AT91_SAM9X60_IER);
+ wdt->mr &= ~AT91_SAM9X60_WDDIS;
+ } else {
+ wdt->mr &= ~AT91_WDT_WDDIS;
+ }
wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
@@ -88,7 +101,12 @@ static int sama5d4_wdt_stop(struct watchdog_device *wdd)
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
- wdt->mr |= AT91_WDT_WDDIS;
+ if (wdt->data->sam9x60_support) {
+ writel_relaxed(wdt->ir, wdt->reg_base + AT91_SAM9X60_IDR);
+ wdt->mr |= AT91_SAM9X60_WDDIS;
+ } else {
+ wdt->mr |= AT91_WDT_WDDIS;
+ }
wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
@@ -109,6 +127,14 @@ static int sama5d4_wdt_set_timeout(struct
[PATCH v2 1/2] dt-bindings: watchdog: sama5d4_wdt: add microchip,sam9x60-wdt compatible
From: Eugen Hristev The Atmel sama5d4_wdt needs to be compatible with microchip,sam9x60-wdt The sama5d4_wdt driver is updated to work with both hardware blocks (sama5d4/sama5d2 and sam9x60 based blocks) Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt index 4fec1e3..44727fc 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt @@ -1,7 +1,7 @@ * Atmel SAMA5D4 Watchdog Timer (WDT) Controller Required properties: -- compatible: "atmel,sama5d4-wdt" +- compatible: "atmel,sama5d4-wdt" or "microchip,sam9x60-wdt" - reg: base physical address and length of memory mapped region. Optional properties: -- 2.7.4
Re: [PATCH v5 0/9] i2c: add support for filters
On 07.10.2019 10:47, Eugen Hristev wrote: > > > On 11.09.2019 11:24, Eugen Hristev - M18282 wrote: >> From: Eugen Hristev >> >> Hello, >> >> This series adds support for analog and digital filters for i2c >> controllers >> >> This series is based on the series: >> [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs >> and later >> [PATCH v4 0/9] i2c: add support for filters >> and enhanced to add the bindings for all controllers plus an extra >> bindings >> for the width of the spikes in nanoseconds (digital filters) and cut-off >> frequency (analog filters) >> >> First, bindings are created for >> 'i2c-analog-filter' >> 'i2c-digital-filter' >> 'i2c-digital-filter-width-ns' >> 'i2c-analog-filter-cutoff-frequency' >> >> The support is added in the i2c core to retrieve filter width/cutoff >> frequency >> and add it to the timings structure. >> Next, the at91 driver is enhanced for supporting digital filter, advanced >> digital filter (with selectable spike width) and the analog filter. >> >> Finally the device tree for two boards are modified to make use of the >> new properties. >> >> This series is the result of the comments on the ML in the direction >> requested: to make the bindings globally available for i2c drivers. >> >> Changes in v5: >> - renamed i2c-filter-width-ns to i2c-digital-filter-width-ns as this >> is applicable only to digital filter >> - created new binding i2c-digital-filter-width-ns for analog filters. > > Hello Wolfram and Peter, > > Are you happy with the changes in this version? I haven't heard from you > since this latest update. > I am interested to know if anymore changes are required or maybe we can > move further with this support. > > Thanks ! > Eugen > Gentle ping >> >> Changes in v4: >> - renamed i2c-ana-filter to i2c-analog-filter >> - renamed i2c-dig-filter to i2c-digital-filter >> >> Changes in v3: >> - made bindings global for i2c controllers and modified accordingly >> - gave up PADFCDF bit because it's a lack in datasheet >> - the computation on the width of the spike is based on periph clock >> as it >> is done for hold time. >> >> Changes in v2: >> - added device tree bindings and support for enable-ana-filt and >> enable-dig-filt >> - added the new properties to the DT for >> sama5d4_xplained/sama5d2_xplained >> >> Eugen Hristev (9): >>   dt-bindings: i2c: at91: add new compatible >>   dt-bindings: i2c: add bindings for i2c analog and digital filter >>   i2c: add support for filters optional properties >>   i2c: at91: add new platform support for sam9x60 >>   i2c: at91: add support for digital filtering >>   i2c: at91: add support for advanced digital filtering >>   i2c: at91: add support for analog filtering >>   ARM: dts: at91: sama5d2_xplained: add analog and digital filter for >> i2c >>   ARM: dts: at91: sama5d4_xplained: add digital filter for i2c >> >>  Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +- >>  Documentation/devicetree/bindings/i2c/i2c.txt | 18 >>  arch/arm/boot/dts/at91-sama5d2_xplained.dts   | 6 +++ >>  arch/arm/boot/dts/at91-sama5d4_xplained.dts   | 1 + >>  drivers/i2c/busses/i2c-at91-core.c | 38 >> + >>  drivers/i2c/busses/i2c-at91-master.c  | 49 >> -- >>  drivers/i2c/busses/i2c-at91.h | 13 ++ >>  drivers/i2c/i2c-core-base.c   | 6 +++ >>  include/linux/i2c.h   | 6 +++ >>  9 files changed, 136 insertions(+), 4 deletions(-) >>
Re: [PATCH 2/3] watchdog: sam9x60_wdt: introduce sam9x60 watchdog timer driver
On 07.10.2019 16:14, Alexandre Belloni wrote: > > On 07/10/2019 05:36:38-0700, Guenter Roeck wrote: >> On 10/7/19 12:58 AM, eugen.hris...@microchip.com wrote: >> [ ... ] >>> Hello Guenter, >>> >>> Thank you for the feedback. >>> After reviewing this, can you please guide me towards one of the >>> possible two directions: merge this driver with sama5d4_wdt , and have a >>> single driver with support for both hardware blocks; or, have this >>> driver separately , as in this patch series? >>> >> >> I noticed the similarities. I don't know if it makes sense to reconcile >> the two drivers; it seems to me the new chip uses the same basic core with >> enhancements. In general, I prefer a single driver, but only if the result >> doesn't end up being an if/else mess. Ultimately, it is really your call >> to make. >> > > Most if not all your comments were already addressed in the other > driver. The main difference in the register interface is the location of > the counter that only really affects sama5d4_wdt_set_timeout and that > could be abstracted away by using a different struct watchdog_ops. > Interrupt enabling is also done differently, I don't think it has a huge > impact. > Thank you Guenter and Alexandre, I will start working on a v2 with a merged driver. Thanks again, Eugen
Re: [PATCH 2/3] watchdog: sam9x60_wdt: introduce sam9x60 watchdog timer driver
On 02.10.2019 16:16, Guenter Roeck wrote:
>
> On 10/2/19 12:35 AM, eugen.hris...@microchip.com wrote:
>> From: Eugen Hristev
>>
>> This is the driver for SAM9X60 watchdog timer.
>> The offered functionality is the same as sama5d4_wdt.
>> The difference comes in register map, way to configure the timeout and
>> interrupts.
>> Developed starting from sama5d4_wdt.c
>>
>> Signed-off-by: Eugen Hristev
>> ---
>>  drivers/watchdog/Kconfig  |  9 ++
>>  drivers/watchdog/Makefile |  1 +
>> Â drivers/watchdog/sam9x60_wdt.c | 335
>> +
>> Â 3 files changed, 345 insertions(+)
>> Â create mode 100644 drivers/watchdog/sam9x60_wdt.c
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 58e7c10..3562e26 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -416,6 +416,15 @@ config SAMA5D4_WATCHDOG
>> Â Â Â Its Watchdog Timer Mode Register can be written more than once.
>> Â Â Â This will reboot your system when the timeout is reached.
>> +config SAM9X60_WATCHDOG
>> +Â Â Â tristate "Microchip SAM9X60 Watchdog Timer"
>> +Â Â Â depends on ARCH_AT91 || COMPILE_TEST
>
> depends on HAS_IOMEM
>
>> +Â Â Â select WATCHDOG_CORE
>> +Â Â Â help
>> +Â Microchip SAM9X60 watchdog timer is embedded into SAM9X60 chips.
>> +Â Its Watchdog Timer Mode Register can be written more than once.
>> +Â This will reboot your system when the timeout is reached.
>> +
>> Â config CADENCE_WATCHDOG
>> Â tristate "Cadence Watchdog Timer"
>> Â depends on HAS_IOMEM
>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>> index 2ee352b..93ba599 100644
>> --- a/drivers/watchdog/Makefile
>> +++ b/drivers/watchdog/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
>> Â obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o
>> Â obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o
>> Â obj-$(CONFIG_SAMA5D4_WATCHDOG) += sama5d4_wdt.o
>> +obj-$(CONFIG_SAM9X60_WATCHDOG) += sam9x60_wdt.o
>> Â obj-$(CONFIG_DW_WATCHDOG) += dw_wdt.o
>> Â obj-$(CONFIG_EP93XX_WATCHDOG) += ep93xx_wdt.o
>> Â obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
>> diff --git a/drivers/watchdog/sam9x60_wdt.c
>> b/drivers/watchdog/sam9x60_wdt.c
>> new file mode 100644
>> index ..f612230
>> --- /dev/null
>> +++ b/drivers/watchdog/sam9x60_wdt.c
>> @@ -0,0 +1,335 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Driver for Microchip SAM9X60 Watchdog Timer
>> + *
>> + * Copyright (C) 2019 Microchip Technology, Inc.
>> + * Author: Eugen Hristev
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define AT91_WDT_CRÂ Â Â 0x00Â Â Â /* Watchdog Control
>> Register */
>> +#define   AT91_WDT_WDRSTT   BIT(0)   /* Restart */
>> +#define   AT91_WDT_KEY   (0xa5 << 24)   /* KEY
>> Password */
>> +
>> +#define AT91_WDT_MRÂ Â Â 0x04Â Â Â /* Watchdog Mode Register */
>> +#define   AT91_WDT_PERIODRST   BIT(4)   /* Period Reset */
>> +#define   AT91_WDT_RPTHRST   BIT(5)   /* Minimum Restart
>> Period */
>> +#define   AT91_WDT_WDDIS   BIT(12)   /* Disable */
>> +#define   AT91_WDT_WDDBGHLT   BIT(28)   /* Debug Halt */
>> +#define   AT91_WDT_WDIDLEHLT   BIT(29)   /* Idle Halt */
>> +
>> +#define AT91_WDT_VRÂ Â Â 0x08Â Â Â /* Watchdog Timer Value
>> Register */
>> +
>> +#define AT91_WDT_WLRÂ Â Â 0x0c
>> +#define   AT91_WDT_COUNTER   (0xfff << 0)   /* Watchdog
>> Period Value */
>> +#define   AT91_WDT_SET_COUNTER(x)   ((x) & AT91_WDT_COUNTER)
>> +
>> +#define AT91_WDT_IERÂ Â Â 0x14Â Â Â /* Interrupt Enable
>> Register */
>> +#define   AT91_WDT_PERINT   BIT(0)   /* Period
>> Interrupt Enable */
>> +#define AT91_WDT_IDRÂ Â Â 0x18Â Â Â /* Interrupt Disable
>> Register */
>> +#define AT91_WDT_ISR   0x1c   /* Interrupt Status
>> Register */
>> +
>> +/* minimum and maximum watchdog timeout, in seconds */
>> +#define MIN_WDT_TIMEOUTÂ Â Â 1
>> +#define MAX_WDT_TIMEOUTÂ Â Â 16
>> +#define WDT_DEFAULT_TIMEOUTÂ Â Â MAX_WDT_TIMEOUT
>> +
>> +#define WDT_SEC2TICKS(s)Â Â Â ((s) ? (((s) << 8) - 1) : 0)
>> +
>> +struct sam9x60_wdt {
>> +   struct watchdog_device   wdd;
>> +   void __iomem   *reg_base;
>> +Â Â Â u32Â Â Â mr;
>> +Â Â Â u32Â Â Â ir;
>> +   unsigned long   last_ping;
>> +};
>> +
>> +static int wdt_timeout;
>> +static bool nowayout = WATCHDOG_NOWAYOUT;
>> +
>> +module_param(wdt_timeout, int, 0);
>> +MODULE_PARM_DESC(wdt_timeout,
>> + "Watchdog timeout in seconds. (default = "
>> + __MODULE_STRING(WDT_DEFAULT_TIMEOUT) ")");
>> +
>> +module_param(nowayout, bool, 0);
>> +MODULE_PARM_DESC(nowayout,
>> + "Watchdog cannot be stopped once started (default="
>> + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
>> +
>>
Re: [PATCH v5 0/9] i2c: add support for filters
On 11.09.2019 11:24, Eugen Hristev - M18282 wrote: > From: Eugen Hristev > > Hello, > > This series adds support for analog and digital filters for i2c controllers > > This series is based on the series: > [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs > and later > [PATCH v4 0/9] i2c: add support for filters > and enhanced to add the bindings for all controllers plus an extra bindings > for the width of the spikes in nanoseconds (digital filters) and cut-off > frequency (analog filters) > > First, bindings are created for > 'i2c-analog-filter' > 'i2c-digital-filter' > 'i2c-digital-filter-width-ns' > 'i2c-analog-filter-cutoff-frequency' > > The support is added in the i2c core to retrieve filter width/cutoff frequency > and add it to the timings structure. > Next, the at91 driver is enhanced for supporting digital filter, advanced > digital filter (with selectable spike width) and the analog filter. > > Finally the device tree for two boards are modified to make use of the > new properties. > > This series is the result of the comments on the ML in the direction > requested: to make the bindings globally available for i2c drivers. > > Changes in v5: > - renamed i2c-filter-width-ns to i2c-digital-filter-width-ns as this > is applicable only to digital filter > - created new binding i2c-digital-filter-width-ns for analog filters. Hello Wolfram and Peter, Are you happy with the changes in this version? I haven't heard from you since this latest update. I am interested to know if anymore changes are required or maybe we can move further with this support. Thanks ! Eugen > > Changes in v4: > - renamed i2c-ana-filter to i2c-analog-filter > - renamed i2c-dig-filter to i2c-digital-filter > > Changes in v3: > - made bindings global for i2c controllers and modified accordingly > - gave up PADFCDF bit because it's a lack in datasheet > - the computation on the width of the spike is based on periph clock as it > is done for hold time. > > Changes in v2: > - added device tree bindings and support for enable-ana-filt and > enable-dig-filt > - added the new properties to the DT for sama5d4_xplained/sama5d2_xplained > > Eugen Hristev (9): >dt-bindings: i2c: at91: add new compatible >dt-bindings: i2c: add bindings for i2c analog and digital filter >i2c: add support for filters optional properties >i2c: at91: add new platform support for sam9x60 >i2c: at91: add support for digital filtering >i2c: at91: add support for advanced digital filtering >i2c: at91: add support for analog filtering >ARM: dts: at91: sama5d2_xplained: add analog and digital filter for > i2c >ARM: dts: at91: sama5d4_xplained: add digital filter for i2c > > Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +- > Documentation/devicetree/bindings/i2c/i2c.txt | 18 > arch/arm/boot/dts/at91-sama5d2_xplained.dts| 6 +++ > arch/arm/boot/dts/at91-sama5d4_xplained.dts| 1 + > drivers/i2c/busses/i2c-at91-core.c | 38 + > drivers/i2c/busses/i2c-at91-master.c | 49 > -- > drivers/i2c/busses/i2c-at91.h | 13 ++ > drivers/i2c/i2c-core-base.c| 6 +++ > include/linux/i2c.h| 6 +++ > 9 files changed, 136 insertions(+), 4 deletions(-) >
Re: [PATCH 2/2] ARM: dts: at91: sama5d27_som1_ek: add mmc capabilities for SDMMC0
On 13.08.2019 09:53, Ludovic Desroches wrote: > On Mon, Aug 12, 2019 at 03:38:34PM +, eugen.hris...@microchip.com wrote: >> On 09.08.2019 09:23, Ludovic Desroches wrote: >>> On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote: On 8/08/19 3:42 PM, Ludovic Desroches wrote: > On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote: >> From: Eugen Hristev >> >> Add mmc capabilities for SDMMC0 for this board. >> With this enabled, eMMC connected card is detected as: >> >> mmc0: new DDR MMC card at address 0001 >> >> Signed-off-by: Eugen Hristev > Acked-by: Ludovic Desroches > > I am interested to have the some insights about the use of sd-uhs-* > properties. > > Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can > be used as the logic control input of a mux. So even if the IP claims > to support UHS modes, it depends on the board. > > Are the sd-uhs-* properties a way to deal with this? I tend to think no > as sdhci_setup_host() will set the caps depending on the content of the > capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS > quirk or sdhci-caps/sdhci-caps-mask? There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports: sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property() if (device_property_present(dev, "no-1-8-v")) host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; >>> >>> Right, I forgot this property. Thanks. >>> >>> Eugen, do you see cases we can't cover with this property? >> >> Hi, >> >> For current requirements and driver support, this should be enough. >> >> I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104 >> the class 10 uhs1 cards are detected as SDR104 . Without this property >> they are detected as DDR50. Any idea why the difference ? The controller >> does not claim to have SDR104 support ? We should add it ? > > With the mainline, our tree or both? In our tree, SDR104 is removed from > the capabilities. > > Ludovic > Hello Alexandre, Anything more needed regarding this patch ? Thanks, Eugen
Re: [PATCH 2/3] watchdog: sam9x60_wdt: introduce sam9x60 watchdog timer driver
On 02.10.2019 13:23, Alexandre Belloni wrote:
> Hi,
>
> On 02/10/2019 07:35:26+, eugen.hris...@microchip.com wrote:
>> +static void wdt_write(struct sam9x60_wdt *wdt, u32 field, u32 val)
>> +{
>> +/*
>> + * WDT_CR and WDT_MR must not be modified within three slow clock
>> + * periods following a restart of the watchdog performed by a write
>> + * access in WDT_CR.
>> + */
>> +while (time_before(jiffies, wdt->last_ping + WDT_DELAY))
>> +usleep_range(30, 125);
>> +writel_relaxed(val, wdt->reg_base + field);
>> +wdt->last_ping = jiffies;
>> +}
>> +
>> +static void wdt_write_nosleep(struct sam9x60_wdt *wdt, u32 field, u32 val)
>> +{
>> +if (time_before(jiffies, wdt->last_ping + WDT_DELAY))
>> +usleep_range(123, 250);
>
> So you have a _nosleep function that does sleep?
>
>> +writel_relaxed(val, wdt->reg_base + field);
>> +wdt->last_ping = jiffies;
>> +}
>> +
>> +static int sam9x60_wdt_start(struct watchdog_device *wdd)
>> +{
>> +struct sam9x60_wdt *wdt = watchdog_get_drvdata(wdd);
>> +
>> +wdt->mr &= ~AT91_WDT_WDDIS;
>> +wdt_write(wdt, AT91_WDT_MR, wdt->mr);
>> +wdt_write_nosleep(wdt, AT91_WDT_IER, wdt->ir);
>
> I don't think AT91_WDT_IER needs to be protected, you can probably write
> it directly. Also, you certainly need to do that before starting the
> watchdog to avoid race conditions.
>
>> +
>> +return 0;
>> +}
>> +
>> +static int sam9x60_wdt_stop(struct watchdog_device *wdd)
>> +{
>> +struct sam9x60_wdt *wdt = watchdog_get_drvdata(wdd);
>> +
>> +wdt->mr |= AT91_WDT_WDDIS;
>> +wdt_write(wdt, AT91_WDT_MR, wdt->mr);
>> +wdt_write_nosleep(wdt, AT91_WDT_IDR, wdt->ir);
>> +
>
> I don't think AT91_WDT_IDR needs to be protected.
>
>> +return 0;
>> +}
>> +
>> +static int sam9x60_wdt_ping(struct watchdog_device *wdd)
>> +{
>> +struct sam9x60_wdt *wdt = watchdog_get_drvdata(wdd);
>> +
>> +wdt_write(wdt, AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
>> +
>> +return 0;
>> +}
>> +
>> +static int sam9x60_wdt_set_timeout(struct watchdog_device *wdd,
>> + unsigned int timeout)
>> +{
>> +struct sam9x60_wdt *wdt = watchdog_get_drvdata(wdd);
>> +
>> +wdt_write(wdt, AT91_WDT_WLR,
>> + AT91_WDT_SET_COUNTER(WDT_SEC2TICKS(timeout)));
>> +
>
> I don't think AT91_WDT_WLR needs to be protected.
>
>> +wdd->timeout = timeout;
>> +
>> +return 0;
>> +}
>> +
>> +static const struct watchdog_info sam9x60_wdt_info = {
>> +.options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
>> +.identity = "Microchip SAM9X60 Watchdog",
>> +};
>> +
>> +static const struct watchdog_ops sam9x60_wdt_ops = {
>> +.owner = THIS_MODULE,
>> +.start = sam9x60_wdt_start,
>> +.stop = sam9x60_wdt_stop,
>> +.ping = sam9x60_wdt_ping,
>> +.set_timeout = sam9x60_wdt_set_timeout,
>> +};
>> +
>> +static irqreturn_t sam9x60_wdt_irq_handler(int irq, void *dev_id)
>> +{
>> +struct sam9x60_wdt *wdt = platform_get_drvdata(dev_id);
>> +
>> +if (wdt_read(wdt, AT91_WDT_ISR)) {
>> +pr_crit("Microchip Watchdog Software Reset\n");
>> +emergency_restart();
>> +pr_crit("Reboot didn't succeed\n");
>> +}
>
> I'm not really convinced by the software restart use case but I guess it
> is to be able to shut down while still flushing data to the storage.
> This would not protect against kernel issues then.
Hi Alexandre,
That's correct. It is to do a software shutdown instead of hard reboot
by hardware. It has it;s use cases, so I preserved the same level of
functionality as in sama5d4_wdt
>
>> +
>> +return IRQ_HANDLED;
>> +}
>> +
>> +static int of_sam9x60_wdt_init(struct device_node *np, struct sam9x60_wdt
>> *wdt)
>> +{
>> +const char *tmp;
>> +
>> +wdt->mr = AT91_WDT_WDDIS;
>> +
>> +if (!of_property_read_string(np, "atmel,watchdog-type", ) &&
>> +!strcmp(tmp, "software"))
>> +wdt->ir = AT91_WDT_PERINT;
>> +else
>> +wdt->mr |= AT91_WDT_PERIODRST;
>> +
>> +if (of_property_read_bool(np, "atmel,idle-halt"))
>> +wdt->mr |= AT91_WDT_WDIDLEHLT;
>> +
>> +if (of_property_read_bool(np, "atmel,dbg-halt"))
>> +wdt->mr |= AT91_WDT_WDDBGHLT;
>> +
>> +return 0;
>> +}
>> +
>> +static int sam9x60_wdt_init(struct sam9x60_wdt *wdt)
>> +{
>> +u32 reg;
>> +/*
>> + * When booting and resuming, the bootloader may have changed the
>> + * watchdog configuration.
>> + * If the watchdog is already running, we can safely update it.
>> + * Else, we have to disable it properly.
>> + */
>> +if (wdt_enabled) {
>> +wdt_write_nosleep(wdt, AT91_WDT_MR, wdt->mr);
>> +wdt_write_nosleep(wdt, AT91_WDT_IER, wdt->ir);
>> +wdt_write(wdt, AT91_WDT_WLR,
>> +
>> AT91_WDT_SET_COUNTER(WDT_SEC2TICKS(WDT_DEFAULT_TIMEOUT)));
>> +
>> +} else {
>> +reg =
[PATCH 1/3] dt-bindings: watchdog: sam9x60_wdt: add bindings
From: Eugen Hristev
Add bindings for Microchip SAM9X60 Watchdog Timer
It has the same bindings as
Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt
except the compatible.
Signed-off-by: Eugen Hristev
---
.../devicetree/bindings/watchdog/sam9x60-wdt.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/sam9x60-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/sam9x60-wdt.txt
b/Documentation/devicetree/bindings/watchdog/sam9x60-wdt.txt
new file mode 100644
index ..74b4e2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sam9x60-wdt.txt
@@ -0,0 +1,34 @@
+* Microchip SAM9X60 Watchdog Timer (WDT) Controller
+
+Required properties:
+- compatible: "microchip,sam9x60-wdt"
+- reg: base physical address and length of memory mapped region.
+
+Optional properties:
+- timeout-sec: watchdog timeout value (in seconds).
+- interrupts: interrupt number to the CPU.
+- atmel,watchdog-type: should be "hardware" or "software".
+ "hardware": enable watchdog fault reset. A watchdog fault triggers
+ watchdog reset.
+ "software": enable watchdog fault interrupt. A watchdog fault asserts
+ watchdog interrupt.
+- atmel,idle-halt: present if you want to stop the watchdog when the CPU is
+ in idle state.
+ CAUTION: This property should be used with care, it actually makes the
+ watchdog not counting when the CPU is in idle state, therefore the
+ watchdog reset time depends on mean CPU usage and will not reset at all
+ if the CPU stop working while it is in idle state, which is probably
+ not what you want.
+- atmel,dbg-halt: present if you want to stop the watchdog when the CPU is
+ in debug state.
+
+Example:
+ watchdog@ff80 {
+ compatible = "microchip,sam9x60-wdt";
+ reg = <0xff80 0x24>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH 5>;
+ timeout-sec = <10>;
+ atmel,watchdog-type = "hardware";
+ atmel,dbg-halt;
+ atmel,idle-halt;
+ };
--
2.7.4
[PATCH 2/3] watchdog: sam9x60_wdt: introduce sam9x60 watchdog timer driver
From: Eugen Hristev
This is the driver for SAM9X60 watchdog timer.
The offered functionality is the same as sama5d4_wdt.
The difference comes in register map, way to configure the timeout and
interrupts.
Developed starting from sama5d4_wdt.c
Signed-off-by: Eugen Hristev
---
drivers/watchdog/Kconfig | 9 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/sam9x60_wdt.c | 335 +
3 files changed, 345 insertions(+)
create mode 100644 drivers/watchdog/sam9x60_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 58e7c10..3562e26 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -416,6 +416,15 @@ config SAMA5D4_WATCHDOG
Its Watchdog Timer Mode Register can be written more than once.
This will reboot your system when the timeout is reached.
+config SAM9X60_WATCHDOG
+ tristate "Microchip SAM9X60 Watchdog Timer"
+ depends on ARCH_AT91 || COMPILE_TEST
+ select WATCHDOG_CORE
+ help
+ Microchip SAM9X60 watchdog timer is embedded into SAM9X60 chips.
+ Its Watchdog Timer Mode Register can be written more than once.
+ This will reboot your system when the timeout is reached.
+
config CADENCE_WATCHDOG
tristate "Cadence Watchdog Timer"
depends on HAS_IOMEM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2ee352b..93ba599 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o
obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o
obj-$(CONFIG_SAMA5D4_WATCHDOG) += sama5d4_wdt.o
+obj-$(CONFIG_SAM9X60_WATCHDOG) += sam9x60_wdt.o
obj-$(CONFIG_DW_WATCHDOG) += dw_wdt.o
obj-$(CONFIG_EP93XX_WATCHDOG) += ep93xx_wdt.o
obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
diff --git a/drivers/watchdog/sam9x60_wdt.c b/drivers/watchdog/sam9x60_wdt.c
new file mode 100644
index ..f612230
--- /dev/null
+++ b/drivers/watchdog/sam9x60_wdt.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Microchip SAM9X60 Watchdog Timer
+ *
+ * Copyright (C) 2019 Microchip Technology, Inc.
+ * Author: Eugen Hristev
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AT91_WDT_CR0x00/* Watchdog Control
Register */
+#defineAT91_WDT_WDRSTT BIT(0) /* Restart */
+#defineAT91_WDT_KEY(0xa5 << 24)/* KEY
Password */
+
+#define AT91_WDT_MR0x04/* Watchdog Mode
Register */
+#defineAT91_WDT_PERIODRST BIT(4) /* Period Reset
*/
+#defineAT91_WDT_RPTHRSTBIT(5) /* Minimum
Restart Period */
+#defineAT91_WDT_WDDIS BIT(12) /* Disable */
+#defineAT91_WDT_WDDBGHLT BIT(28) /* Debug Halt */
+#defineAT91_WDT_WDIDLEHLT BIT(29) /* Idle Halt */
+
+#define AT91_WDT_VR0x08/* Watchdog Timer Value
Register */
+
+#define AT91_WDT_WLR 0x0c
+#defineAT91_WDT_COUNTER(0xfff << 0)/*
Watchdog Period Value */
+#defineAT91_WDT_SET_COUNTER(x) ((x) & AT91_WDT_COUNTER)
+
+#define AT91_WDT_IER 0x14/* Interrupt Enable
Register */
+#defineAT91_WDT_PERINT BIT(0) /* Period
Interrupt Enable */
+#define AT91_WDT_IDR 0x18/* Interrupt Disable
Register */
+#define AT91_WDT_ISR 0x1c/* Interrupt Status
Register */
+
+/* minimum and maximum watchdog timeout, in seconds */
+#define MIN_WDT_TIMEOUT1
+#define MAX_WDT_TIMEOUT16
+#define WDT_DEFAULT_TIMEOUTMAX_WDT_TIMEOUT
+
+#define WDT_SEC2TICKS(s) ((s) ? (((s) << 8) - 1) : 0)
+
+struct sam9x60_wdt {
+ struct watchdog_device wdd;
+ void __iomem*reg_base;
+ u32 mr;
+ u32 ir;
+ unsigned long last_ping;
+};
+
+static int wdt_timeout;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+module_param(wdt_timeout, int, 0);
+MODULE_PARM_DESC(wdt_timeout,
+"Watchdog timeout in seconds. (default = "
+__MODULE_STRING(WDT_DEFAULT_TIMEOUT) ")");
+
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+"Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+#define wdt_enabled (!(wdt->mr & AT91_WDT_WDDIS))
+
+#define wdt_read(wdt, field) \
+ readl_relaxed((wdt)->reg_base + (field))
+
+/* 4 slow clock periods is 4/32768 = 122.07us*/
+#define WDT_DELAY usecs_to_jiffies(123)
+
+static
[PATCH 3/3] MAINTAINERS: add sam9x60_wdt
From: Eugen Hristev Add sam9x60_wdt watchdog driver to at91 soc support. Signed-off-by: Eugen Hristev --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 296de2b..109b030 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1972,6 +1972,7 @@ F:arch/arm/boot/dts/sama*.dtsi F: arch/arm/include/debug/at91.S F: drivers/memory/atmel* F: drivers/watchdog/sama5d4_wdt.c +F: drivers/watchdog/sam9x60_wdt.c X: drivers/input/touchscreen/atmel_mxt_ts.c X: drivers/net/wireless/atmel/ -- 2.7.4
[PATCH] clk: at91: sam9x60: fix programmable clock
From: Eugen Hristev
The prescaler mask for sam9x60 must be 0xff (8 bits).
Being set to 0, means that we cannot set any prescaler, thus the
programmable clocks do not work (except the case with prescaler 0)
Set the mask accordingly in layout struct.
Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver")
Signed-off-by: Eugen Hristev
---
drivers/clk/at91/sam9x60.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
index 9790ddf..86238d5 100644
--- a/drivers/clk/at91/sam9x60.c
+++ b/drivers/clk/at91/sam9x60.c
@@ -43,6 +43,7 @@ static const struct clk_pll_characteristics
upll_characteristics = {
};
static const struct clk_programmable_layout sam9x60_programmable_layout = {
+ .pres_mask = 0xff,
.pres_shift = 8,
.css_mask = 0x1f,
.have_slck_mck = 0,
--
2.7.4
Re: [PATCH 2/3] mmc: sdhci-of-at91: rework clocks management to support SAM9x60 device
On 12.09.2019 23:09, Ludovic Desroches wrote:
>
> In the SAM9x60 SoC, there are only two clocks instead of three for the
> SDHCI device. The base clk is no longer provided, it is generated
> internally from the mult clk.
>
> The values of the base clk and mul in the capabilities registers may not
> reflect the reality as the mult clk is a programmable clock which can take
> several rates. As we can't trust those values, take them from the clock
> tree and update the capabilities according to.
>
> As we can have the same pitfall, in some cases, with the SAMA5D2 Soc,
> stop relying on capabilities too.
>
> Signed-off-by: Ludovic Desroches
> ---
> drivers/mmc/host/sdhci-of-at91.c | 104 +--
> 1 file changed, 57 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-at91.c
> b/drivers/mmc/host/sdhci-of-at91.c
> index e7d1920729fb..a9c126f14d85 100644
> --- a/drivers/mmc/host/sdhci-of-at91.c
> +++ b/drivers/mmc/host/sdhci-of-at91.c
> @@ -30,7 +30,14 @@
>
> #define SDHCI_AT91_PRESET_COMMON_CONF 0x400 /* drv type B,
> programmable clock mode */
>
> +struct sdhci_at91_soc_data {
> + const struct sdhci_pltfm_data *pdata;
> + bool baseclk_is_generated_internally;
> + unsigned int divider_for_baseclk;
> +};
> +
> struct sdhci_at91_priv {
> + const struct sdhci_at91_soc_data *soc_data;
> struct clk *hclock;
> struct clk *gck;
> struct clk *mainck;
> @@ -130,12 +137,24 @@ static const struct sdhci_ops sdhci_at91_sama5d2_ops = {
> .set_power = sdhci_at91_set_power,
> };
>
> -static const struct sdhci_pltfm_data soc_data_sama5d2 = {
> +static const struct sdhci_pltfm_data sdhci_sama5d2_pdata = {
> .ops = _at91_sama5d2_ops,
> };
>
> +static const struct sdhci_at91_soc_data soc_data_sama5d2 = {
> + .pdata = _sama5d2_pdata,
> + .baseclk_is_generated_internally = false,
> +};
> +
> +static const struct sdhci_at91_soc_data soc_data_sam9x60 = {
> + .pdata = _sama5d2_pdata,
> + .baseclk_is_generated_internally = true,
> + .divider_for_baseclk = 2,
> +};
> +
> static const struct of_device_id sdhci_at91_dt_match[] = {
> { .compatible = "atmel,sama5d2-sdhci", .data = _data_sama5d2 },
> + { .compatible = "microchip,sam9x60-sdhci", .data = _data_sam9x60 },
> {}
> };
> MODULE_DEVICE_TABLE(of, sdhci_at91_dt_match);
> @@ -145,50 +164,36 @@ static int sdhci_at91_set_clks_presets(struct device
> *dev)
> struct sdhci_host *host = dev_get_drvdata(dev);
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
> - int ret;
> unsigned intcaps0, caps1;
> unsigned intclk_base, clk_mul;
> - unsigned intgck_rate, real_gck_rate;
> + unsigned intgck_rate, clk_base_rate;
> unsigned intpreset_div;
>
> - /*
> - * The mult clock is provided by as a generated clock by the PMC
> - * controller. In order to set the rate of gck, we have to get the
> - * base clock rate and the clock mult from capabilities.
> - */
> clk_prepare_enable(priv->hclock);
> caps0 = readl(host->ioaddr + SDHCI_CAPABILITIES);
> caps1 = readl(host->ioaddr + SDHCI_CAPABILITIES_1);
> - clk_base = (caps0 & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
> - clk_mul = (caps1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
> - gck_rate = clk_base * 100 * (clk_mul + 1);
> - ret = clk_set_rate(priv->gck, gck_rate);
> - if (ret < 0) {
> - dev_err(dev, "failed to set gck");
> - clk_disable_unprepare(priv->hclock);
> - return ret;
> - }
> - /*
> - * We need to check if we have the requested rate for gck because in
> - * some cases this rate could be not supported. If it happens, the rate
> - * is the closest one gck can provide. We have to update the value
> - * of clk mul.
> - */
> - real_gck_rate = clk_get_rate(priv->gck);
> - if (real_gck_rate != gck_rate) {
> - clk_mul = real_gck_rate / (clk_base * 100) - 1;
> - caps1 &= (~SDHCI_CLOCK_MUL_MASK);
> - caps1 |= ((clk_mul << SDHCI_CLOCK_MUL_SHIFT) &
> - SDHCI_CLOCK_MUL_MASK);
> - /* Set capabilities in r/w mode. */
> - writel(SDMMC_CACR_KEY | SDMMC_CACR_CAPWREN,
> -host->ioaddr + SDMMC_CACR);
> - writel(caps1, host->ioaddr + SDHCI_CAPABILITIES_1);
> - /* Set capabilities in ro mode. */
> - writel(0, host->ioaddr + SDMMC_CACR);
> - dev_info(dev, "update clk mul to %u as gck rate is %u Hz\n",
> - clk_mul, real_gck_rate);
> - }
> +
> + gck_rate = clk_get_rate(priv->gck);
> + if
Re: [PATCH] clk: at91: allow 24 Mhz clock as input for PLL
On 16.09.2019 22:52, Stephen Boyd wrote:
> Quoting eugen.hris...@microchip.com (2019-09-10 23:39:20)
>> From: Eugen Hristev
>>
>> The PLL input range needs to be able to allow 24 Mhz crystal as input
>> Update the range accordingly in plla characteristics struct
>>
>> Signed-off-by: Eugen Hristev
>> ---
>
> Is there a Fixes: tag for this? Seems like it was always wrong?
>
Hi Stephen,
At the initial design , the 12 Mhz was the only possibility for the
boards themselves. But, with the commit who added this:
Fixes: c561e41ce4d2 ("clk: at91: add sama5d2 PMC driver")
Eugen
Re: [PATCH] clk: at91: allow 24 Mhz clock as input for PLL
On 12.09.2019 14:06, Alexander Dahl wrote:
>
> Hello,
>
> out of curiosity: The SAMA5D27-SOM1-EK board has a 24 MHz crystal, that is
> also what /sys/kernel/debug/clk/clk_summary says and the board runs without
> obvious problems. What is this change improving in real practice then?
>
The board works, but, the characteristics of the PLL are incorrect.
This can lead to unwanted behavior, like calculating wrong minimum
values for multipliers, or other issues
In this code here in clk-pll.c for example
if (parent_rate > characteristics->input.max) {
tmpdiv = DIV_ROUND_UP(parent_rate,
characteristics->input.max);
if (tmpdiv > PLL_DIV_MAX)
return -ERANGE;
if (tmpdiv > mindiv)
mindiv = tmpdiv;
}
The divisor is capped by checks, but at another possible requested
parent rate, this may lead to something wrong, like here, the minimum
divisor might be greater than what is the real possible one. So in some
cases it can happen that unwanted results occur.
We may consider at some points to rely on these values more, so, it's
obvious that they should be correct in the characteristics
So short answer: no improve in your case , where the rates required are
around 492 Mhz cpu/132 mhz bus (IIRC), but the characteristics need to
be correct to cover all possible cases.
Eugen
> Greets
> Alex
>
> Am Mittwoch, 11. September 2019, 06:39:20 CEST schrieb
> eugen.hris...@microchip.com:
>> From: Eugen Hristev
>>
>> The PLL input range needs to be able to allow 24 Mhz crystal as input
>> Update the range accordingly in plla characteristics struct
>>
>> Signed-off-by: Eugen Hristev
>> ---
>> drivers/clk/at91/sama5d2.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
>> index 6509d09..0de1108 100644
>> --- a/drivers/clk/at91/sama5d2.c
>> +++ b/drivers/clk/at91/sama5d2.c
>> @@ -21,7 +21,7 @@ static const struct clk_range plla_outputs[] = {
>> };
>>
>> static const struct clk_pll_characteristics plla_characteristics = {
>> -.input = { .min = 1200, .max = 1200 },
>> +.input = { .min = 1200, .max = 2400 },
>> .num_output = ARRAY_SIZE(plla_outputs),
>> .output = plla_outputs,
>> .icpll = plla_icpll,
>
>
>
>
[PATCH v5 5/9] i2c: at91: add support for digital filtering
From: Eugen Hristev
Add new platform data support for digital filtering for i2c.
The sama5d4, sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 9 +
drivers/i2c/busses/i2c-at91.h| 5 +
3 files changed, 23 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index caf1846..e96360f 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_unre_flag = true,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -154,6 +162,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index a3fcc35..df80557 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -31,12 +31,18 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
+ struct at91_twi_pdata *pdata = dev->pdata;
+
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_MSEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SVDIS);
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
+
+ /* enable digital filter */
+ if (pdata->has_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
}
/*
@@ -793,6 +799,9 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
}
+ dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
+"i2c-digital-filter");
+
at91_calc_twi_clock(dev);
dev->adapter.algo = _twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 499b506..c75447e 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -84,6 +84,9 @@
#defineAT91_TWI_ACR_DATAL(len) ((len) & 0xff)
#defineAT91_TWI_ACR_DIRBIT(8)
+#define AT91_TWI_FILTR 0x0044
+#define AT91_TWI_FILTR_FILTBIT(0)
+
#defineAT91_TWI_FMR0x0050 /* FIFO Mode Register */
#defineAT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
#defineAT91_TWI_FMR_TXRDYM_MASK(0x3 << 0)
@@ -108,6 +111,7 @@ struct at91_twi_pdata {
bool has_unre_flag;
bool has_alt_cmd;
bool has_hold_field;
+ bool has_dig_filtr;
struct at_dma_slave dma_slave;
};
@@ -145,6 +149,7 @@ struct at91_twi_dev {
unsigned smr;
struct i2c_client *slave;
[PATCH v5 7/9] i2c: at91: add support for analog filtering
From: Eugen Hristev
Add support for analog filtering for i2c lines.
The sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 18 ++
drivers/i2c/busses/i2c-at91.h| 3 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 1f4ee7e..e13af48 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -70,6 +70,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -80,6 +81,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -90,6 +92,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -100,6 +103,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -110,6 +114,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -142,6 +147,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -152,6 +158,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -162,6 +169,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -172,6 +180,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index 273bd8b..6e0b554 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -32,6 +32,7 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
struct at91_twi_pdata *pdata = dev->pdata;
+ u32 filtr = 0;
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
@@ -42,13 +43,20 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+ filtr |= AT91_TWI_FILTR_FILT;
/* enable advanced digital filter */
if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
- (AT91_TWI_FILTR_THRES(dev->filter_width) &
- AT91_TWI_FILTR_THRES_MASK));
+ filtr |= AT91_TWI_FILTR_FILT |
+(AT91_TWI_FILTR_THRES(dev->filter_width) &
+AT91_TWI_FILTR_THRES_MASK);
+
+ /* enable analog filter */
+ if (pdata->has_ana_filtr && dev->enable_ana_filt)
+ filtr |= AT91_TWI_FILTR_PADFEN;
+
+ if (filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, filtr);
}
/*
@@ -826,6 +834,8 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
"i2c-digital-filter");
+ dev->enable_ana_filt = of_property_read_bool(pdev->dev.of_node,
+"i2c-analog-filter");
at91_calc_twi_clock(dev);
dev->adapter.algo = _twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index d7cf01e3..977a67b 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++
[PATCH v5 4/9] i2c: at91: add new platform support for sam9x60
From: Eugen Hristev
Add new platform data support for the sam9x60 SoC
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 435c7d7..caf1846 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -148,6 +148,14 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
};
+static struct at91_twi_pdata sam9x60_config = {
+ .clk_max_div = 7,
+ .clk_offset = 4,
+ .has_unre_flag = true,
+ .has_alt_cmd = true,
+ .has_hold_field = true,
+};
+
static const struct of_device_id atmel_twi_dt_ids[] = {
{
.compatible = "atmel,at91rm9200-i2c",
@@ -174,6 +182,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
.compatible = "atmel,sama5d2-i2c",
.data = _config,
}, {
+ .compatible = "microchip,sam9x60-i2c",
+ .data = _config,
+ }, {
/* sentinel */
}
};
--
2.7.4
[PATCH v5 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Eugen Hristev Some i2c controllers have a built-in digital or analog filter. This is specifically required depending on the hardware PCB/board. Some controllers also allow specifying the maximum width of the spikes that can be filtered for digital filter. The width length can be specified in nanoseconds. Analog filters can be configured to have a cutoff frequency (low-pass filter). This frequency can be specified in Hz. Added an optional property for such types of analog filters. Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/i2c/i2c.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index 44efafd..9a53df4 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -55,6 +55,24 @@ wants to support one of the below features, it should adapt the bindings below. Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C specification. +- i2c-analog-filter + Enable analog filter for i2c lines. + +- i2c-digital-filter + Enable digital filter for i2c lines. + +- i2c-digital-filter-width-ns + Width of spikes which can be filtered by digital filter + (i2c-digital-filter). This width is specified in nanoseconds. + +- i2c-analog-filter-cutoff-frequency + Frequency that the analog filter (i2c-analog-filter) uses to distinguish + which signal to filter. Signal with higher frequency than specified will + be filtered out. Only lower frequency will pass (this is applicable to + a low-pass analog filter). Typical value should be above the normal + i2c bus clock frequency (clock-frequency). + Specified in Hz. + - interrupts interrupts used by the device. -- 2.7.4
[PATCH v5 3/9] i2c: add support for filters optional properties
From: Eugen Hristev
i2c-digital-filter-width-ns:
This optional timing property specifies the width of the spikes on the i2c
lines (in ns) that can be filtered out by built-in digital filters which are
embedded in some i2c controllers.
i2c-analog-filter-cutoff-frequency:
This optional timing property specifies the cutoff frequency of a low-pass
analog filter built-in i2c controllers. This low pass filter is used to filter
out high frequency noise on the i2c lines. Specified in Hz.
Include these properties in the timings structure and read them as integers.
Signed-off-by: Eugen Hristev
---
drivers/i2c/i2c-core-base.c | 6 ++
include/linux/i2c.h | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 9c440fa..c9fcb16 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1658,6 +1658,12 @@ void i2c_parse_fw_timings(struct device *dev, struct
i2c_timings *t, bool use_de
t->sda_fall_ns = t->scl_fall_ns;
device_property_read_u32(dev, "i2c-sda-hold-time-ns", >sda_hold_ns);
+
+ device_property_read_u32(dev, "i2c-digital-filter-width-ns",
+>digital_filter_width_ns);
+
+ device_property_read_u32(dev, "i2c-analog-filter-cutoff-frequency",
+>analog_filter_cutoff_freq_hz);
}
EXPORT_SYMBOL_GPL(i2c_parse_fw_timings);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fa5552c..26ce143 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -575,6 +575,10 @@ struct i2c_lock_operations {
* @scl_int_delay_ns: time IP core additionally needs to setup SCL in ns
* @sda_fall_ns: time SDA signal takes to fall in ns; t(f) in the I2C
specification
* @sda_hold_ns: time IP core additionally needs to hold SDA in ns
+ * @digital_filter_width_ns: width in ns of spikes on i2c lines that the IP
core
+ * digital filter can filter out
+ * @analog_filter_cutoff_freq_hz: threshold frequency for the low pass IP core
+ analog filter
*/
struct i2c_timings {
u32 bus_freq_hz;
@@ -583,6 +587,8 @@ struct i2c_timings {
u32 scl_int_delay_ns;
u32 sda_fall_ns;
u32 sda_hold_ns;
+ u32 digital_filter_width_ns;
+ u32 analog_filter_cutoff_freq_hz;
};
/**
--
2.7.4
[PATCH v5 8/9] ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c
From: Eugen Hristev
Add property for analog and digital filter for i2c1 and i2c2 nodes
for sama5d2_xplained
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 808e399..9d0a7fb 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -334,6 +334,9 @@
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
atmel,fifo-size = <16>;
+ i2c-analog-filter;
+ i2c-digital-filter;
+ i2c-digital-filter-width-ns = <35>;
status = "okay";
};
};
@@ -342,6 +345,9 @@
dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_i2c1_default>;
+ i2c-analog-filter;
+ i2c-digital-filter;
+ i2c-digital-filter-width-ns = <35>;
status = "okay";
at24@54 {
--
2.7.4
[PATCH v5 9/9] ARM: dts: at91: sama5d4_xplained: add digital filter for i2c
From: Eugen Hristev
Add property for digital filter for i2c0 node sama5d4_xplained
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index fdfc37d..924d949 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -49,6 +49,7 @@
};
i2c0: i2c@f8014000 {
+ i2c-digital-filter;
status = "okay";
};
--
2.7.4
[PATCH v5 6/9] i2c: at91: add support for advanced digital filtering
From: Eugen Hristev
Add new platform data support for advanced digital filtering for i2c.
The sama5d2 and sam9x60 support this feature.
This digital filter allows the user to configure the maximum
width of the spikes that can be filtered.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 30 +++---
drivers/i2c/busses/i2c-at91.h| 5 +
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index e96360f..1f4ee7e 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -69,6 +69,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -78,6 +79,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -87,6 +89,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -96,6 +99,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -105,6 +109,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -136,6 +141,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -145,6 +151,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_alt_cmd = false,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -154,6 +161,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -163,6 +171,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index df80557..273bd8b 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -43,6 +43,12 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+
+ /* enable advanced digital filter */
+ if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(dev->filter_width) &
+ AT91_TWI_FILTR_THRES_MASK));
}
/*
@@ -51,7 +57,7 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
*/
static void at91_calc_twi_clock(struct at91_twi_dev *dev)
{
- int ckdiv, cdiv, div, hold = 0;
+ int ckdiv, cdiv, div, hold = 0, filter_width = 0;
struct at91_twi_pdata *pdata = dev->pdata;
int offset = pdata->clk_offset;
int max_ckdiv = pdata->clk_max_div;
@@ -90,11 +96,29 @@ static void at91_calc_twi_clock(struct at91_twi_dev *dev)
}
}
+ if (pdata->has_adv_dig_filtr) {
+ /*
+* filter width = 0 to AT91_TWI_FILTR_THRES_MAX
+* peripheral clocks
+*/
+ filter_width = DIV_ROUND_UP(t->digital_filter_width_ns
+ * (clk_get_rate(dev->clk) / 1000), 100);
+ if (filter_width > AT91_TWI_FILTR_THRES_MAX) {
+ dev_warn(dev->dev,
+ "Filter threshold set to its maximum value (%d
instead of %d)\n",
+ AT91_TWI_FILTR_THRES_MAX, filter_width);
+ filter_width = AT91_TWI_FILTR_THRES_MAX;
+ }
+ }
+
[PATCH v5 0/9] i2c: add support for filters
From: Eugen Hristev Hello, This series adds support for analog and digital filters for i2c controllers This series is based on the series: [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs and later [PATCH v4 0/9] i2c: add support for filters and enhanced to add the bindings for all controllers plus an extra bindings for the width of the spikes in nanoseconds (digital filters) and cut-off frequency (analog filters) First, bindings are created for 'i2c-analog-filter' 'i2c-digital-filter' 'i2c-digital-filter-width-ns' 'i2c-analog-filter-cutoff-frequency' The support is added in the i2c core to retrieve filter width/cutoff frequency and add it to the timings structure. Next, the at91 driver is enhanced for supporting digital filter, advanced digital filter (with selectable spike width) and the analog filter. Finally the device tree for two boards are modified to make use of the new properties. This series is the result of the comments on the ML in the direction requested: to make the bindings globally available for i2c drivers. Changes in v5: - renamed i2c-filter-width-ns to i2c-digital-filter-width-ns as this is applicable only to digital filter - created new binding i2c-digital-filter-width-ns for analog filters. Changes in v4: - renamed i2c-ana-filter to i2c-analog-filter - renamed i2c-dig-filter to i2c-digital-filter Changes in v3: - made bindings global for i2c controllers and modified accordingly - gave up PADFCDF bit because it's a lack in datasheet - the computation on the width of the spike is based on periph clock as it is done for hold time. Changes in v2: - added device tree bindings and support for enable-ana-filt and enable-dig-filt - added the new properties to the DT for sama5d4_xplained/sama5d2_xplained Eugen Hristev (9): dt-bindings: i2c: at91: add new compatible dt-bindings: i2c: add bindings for i2c analog and digital filter i2c: add support for filters optional properties i2c: at91: add new platform support for sam9x60 i2c: at91: add support for digital filtering i2c: at91: add support for advanced digital filtering i2c: at91: add support for analog filtering ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c ARM: dts: at91: sama5d4_xplained: add digital filter for i2c Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +- Documentation/devicetree/bindings/i2c/i2c.txt | 18 arch/arm/boot/dts/at91-sama5d2_xplained.dts| 6 +++ arch/arm/boot/dts/at91-sama5d4_xplained.dts| 1 + drivers/i2c/busses/i2c-at91-core.c | 38 + drivers/i2c/busses/i2c-at91-master.c | 49 -- drivers/i2c/busses/i2c-at91.h | 13 ++ drivers/i2c/i2c-core-base.c| 6 +++ include/linux/i2c.h| 6 +++ 9 files changed, 136 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v5 1/9] dt-bindings: i2c: at91: add new compatible
From: Eugen Hristev Add compatible for new Microchip SoC, sam9x60 Reviewed-by: Rob Herring Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index b7cec17..2210f43 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt @@ -3,7 +3,8 @@ I2C for Atmel platforms Required properties : - compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c", "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c", - "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c" + "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or + "microchip,sam9x60-i2c" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt number to the cpu. -- 2.7.4
[PATCH] clk: at91: allow 24 Mhz clock as input for PLL
From: Eugen Hristev
The PLL input range needs to be able to allow 24 Mhz crystal as input
Update the range accordingly in plla characteristics struct
Signed-off-by: Eugen Hristev
---
drivers/clk/at91/sama5d2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
index 6509d09..0de1108 100644
--- a/drivers/clk/at91/sama5d2.c
+++ b/drivers/clk/at91/sama5d2.c
@@ -21,7 +21,7 @@ static const struct clk_range plla_outputs[] = {
};
static const struct clk_pll_characteristics plla_characteristics = {
- .input = { .min = 1200, .max = 1200 },
+ .input = { .min = 1200, .max = 2400 },
.num_output = ARRAY_SIZE(plla_outputs),
.output = plla_outputs,
.icpll = plla_icpll,
--
2.7.4
[PATCH 1/2] clk: at91: fix update bit maps on CFG_MOR write
From: Eugen Hristev
The regmap update bits call was not selecting the proper mask, considering
the bits which was updating.
Update the mask from call to also include OSCBYPASS.
Removed MOSCEN which was not updated.
Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally")
Signed-off-by: Eugen Hristev
---
drivers/clk/at91/clk-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
index f607ee7..ebe9b99 100644
--- a/drivers/clk/at91/clk-main.c
+++ b/drivers/clk/at91/clk-main.c
@@ -152,7 +152,7 @@ at91_clk_register_main_osc(struct regmap *regmap,
if (bypass)
regmap_update_bits(regmap,
AT91_CKGR_MOR, MOR_KEY_MASK |
- AT91_PMC_MOSCEN,
+ AT91_PMC_OSCBYPASS,
AT91_PMC_OSCBYPASS | AT91_PMC_KEY);
hw = >hw;
--
2.7.4
[PATCH 2/2] clk: at91: select parent if main oscillator or bypass is enabled
From: Eugen Hristev
Selecting the right parent for the main clock is done using only
main oscillator enabled bit.
In case we have this oscillator bypassed by an external signal (no driving
on the XOUT line), we still use external clock, but with BYPASS bit set.
So, in this case we must select the same parent as before.
Create a macro that will select the right parent considering both bits from
the MOR register.
Use this macro when looking for the right parent.
Signed-off-by: Eugen Hristev
---
drivers/clk/at91/clk-main.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
index ebe9b99..87083b3 100644
--- a/drivers/clk/at91/clk-main.c
+++ b/drivers/clk/at91/clk-main.c
@@ -21,6 +21,10 @@
#define MOR_KEY_MASK (0xff << 16)
+#define clk_main_parent_select(s) (((s) & \
+ (AT91_PMC_MOSCEN | \
+ AT91_PMC_OSCBYPASS)) ? 1 : 0)
+
struct clk_main_osc {
struct clk_hw hw;
struct regmap *regmap;
@@ -113,7 +117,7 @@ static int clk_main_osc_is_prepared(struct clk_hw *hw)
regmap_read(regmap, AT91_PMC_SR, );
- return (status & AT91_PMC_MOSCS) && (tmp & AT91_PMC_MOSCEN);
+ return (status & AT91_PMC_MOSCS) && clk_main_parent_select(tmp);
}
static const struct clk_ops main_osc_ops = {
@@ -450,7 +454,7 @@ static u8 clk_sam9x5_main_get_parent(struct clk_hw *hw)
regmap_read(clkmain->regmap, AT91_CKGR_MOR, );
- return status & AT91_PMC_MOSCEN ? 1 : 0;
+ return clk_main_parent_select(status);
}
static const struct clk_ops sam9x5_main_ops = {
@@ -492,7 +496,7 @@ at91_clk_register_sam9x5_main(struct regmap *regmap,
clkmain->hw.init =
clkmain->regmap = regmap;
regmap_read(clkmain->regmap, AT91_CKGR_MOR, );
- clkmain->parent = status & AT91_PMC_MOSCEN ? 1 : 0;
+ clkmain->parent = clk_main_parent_select(status);
hw = >hw;
ret = clk_hw_register(NULL, >hw);
--
2.7.4
[PATCH v2 1/2] staging: dt-bindings: wilc1000: add optional rtc_clk property
From: Eugen Hristev
Add bindings for optional rtc clock pin.
Signed-off-by: Eugen Hristev
Acked-by: Ajay Singh
---
Changes in v2:
- none
drivers/staging/wilc1000/microchip,wilc1000,sdio.txt | 8 +++-
drivers/staging/wilc1000/microchip,wilc1000,spi.txt | 8
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
b/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
index 4f7d1c2..da52359 100644
--- a/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
+++ b/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
@@ -10,7 +10,9 @@ Required properties:
Optional:
- bus-width: Number of data lines wired up the slot. Default 1 bit.
-
+- rtc_clk : Clock connected on the rtc clock line. Must be assigned
+ a frequency with assigned-clocks property, and must be
+ connected to a clock provider.
Examples:
mmc1: mmc@fc00 {
@@ -24,6 +26,10 @@ mmc1: mmc@fc00 {
wilc_sdio@0 {
compatible = "microchip,wilc1000-sdio";
irq-gpios = < 27 0>;
+ clocks = <>;
+ clock-names = "rtc_clk";
+ assigned-clocks = <>;
+ assigned-clock-rates = <32768>;
status = "okay";
reg = <0>;
bus-width = <4>;
diff --git a/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
b/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
index 87db87b..3423693 100644
--- a/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
+++ b/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
@@ -9,6 +9,10 @@ Required properties:
- reg : Chip select address of device
- irq-gpios: Connect to a host IRQ
+Optional:
+- rtc_clk : Clock connected on the rtc clock line. Must be assigned
+ a frequency with assigned-clocks property, and must be
+ connected to a clock provider.
Examples:
@@ -21,6 +25,10 @@ spi1: spi@fc018000 {
spi-max-frequency = <4800>;
reg = <0>;
irq-gpios = < 27 0>;
+ clocks = <>;
+ clock-names = "rtc_clk";
+ assigned-clocks = <>;
+ assigned-clock-rates = <32768>;
status = "okay";
};
};
--
2.7.4
[PATCH v2 2/2] staging: wilc1000: look for rtc_clk clock
From: Eugen Hristev
If rtc_clk is provided from DT, use it and enable it.
This is optional.
The signal may be hardcoded and no need to be requested,
but if DT provides it, use it.
Signed-off-by: Eugen Hristev
Acked-by: Ajay Singh
---
Changes in v2:
- rebased on staging-next
drivers/staging/wilc1000/wilc_sdio.c | 14 ++
drivers/staging/wilc1000/wilc_wfi_netdevice.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/staging/wilc1000/wilc_sdio.c
b/drivers/staging/wilc1000/wilc_sdio.c
index 2f9aa36..c787c5d 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -4,6 +4,7 @@
* All rights reserved.
*/
+#include
#include
#include
@@ -151,6 +152,12 @@ static int wilc_sdio_probe(struct sdio_func *func,
wilc->dev = >dev;
wilc->gpio_irq = gpio;
+ wilc->rtc_clk = devm_clk_get(>card->dev, "rtc_clk");
+ if (PTR_ERR_OR_ZERO(wilc->rtc_clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ else if (!IS_ERR(wilc->rtc_clk))
+ clk_prepare_enable(wilc->rtc_clk);
+
dev_info(>dev, "Driver Initializing success\n");
return 0;
}
@@ -162,6 +169,10 @@ static void wilc_sdio_remove(struct sdio_func *func)
/* free the GPIO in module remove */
if (wilc->gpio_irq)
gpiod_put(wilc->gpio_irq);
+
+ if (!IS_ERR(wilc->rtc_clk))
+ clk_disable_unprepare(wilc->rtc_clk);
+
wilc_netdev_cleanup(wilc);
}
@@ -193,6 +204,9 @@ static int wilc_sdio_suspend(struct device *dev)
dev_info(dev, "sdio suspend\n");
chip_wakeup(wilc);
+ if (!IS_ERR(wilc->rtc_clk))
+ clk_disable_unprepare(wilc->rtc_clk);
+
if (wilc->suspend_event) {
host_sleep_notify(wilc);
chip_allow_sleep(wilc);
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 7e7ce94..978a8bd 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -216,6 +216,7 @@ struct wilc {
int io_type;
s8 mac_status;
struct gpio_desc *gpio_irq;
+ struct clk *rtc_clk;
bool initialized;
int dev_irq_num;
int close;
--
2.7.4
[PATCH 2/2] staging: wilc1000: look for rtc_clk clock
From: Eugen Hristev
If rtc_clk is provided from DT, use it and enable it.
This is optional.
The signal may be hardcoded and no need to be requested,
but if DT provides it, use it.
Signed-off-by: Eugen Hristev
---
drivers/staging/wilc1000/wilc_sdio.c | 14 ++
drivers/staging/wilc1000/wilc_wfi_netdevice.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/staging/wilc1000/wilc_sdio.c
b/drivers/staging/wilc1000/wilc_sdio.c
index 4c1c81f..41b69fd 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -4,6 +4,7 @@
* All rights reserved.
*/
+#include
#include
#include
@@ -151,6 +152,12 @@ static int wilc_sdio_probe(struct sdio_func *func,
wilc->dev = >dev;
wilc->gpio_irq = gpio;
+ wilc->rtc_clk = devm_clk_get(>card->dev, "rtc_clk");
+ if (PTR_ERR_OR_ZERO(wilc->rtc_clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ else if (!IS_ERR(wilc->rtc_clk))
+ clk_prepare_enable(wilc->rtc_clk);
+
dev_info(>dev, "Driver Initializing success\n");
return 0;
}
@@ -162,6 +169,10 @@ static void wilc_sdio_remove(struct sdio_func *func)
/* free the GPIO in module remove */
if (wilc->gpio_irq)
gpiod_put(wilc->gpio_irq);
+
+ if (!IS_ERR(wilc->rtc_clk))
+ clk_disable_unprepare(wilc->rtc_clk);
+
wilc_netdev_cleanup(wilc);
}
@@ -193,6 +204,9 @@ static int wilc_sdio_suspend(struct device *dev)
dev_info(dev, "sdio suspend\n");
chip_wakeup(wilc);
+ if (!IS_ERR(wilc->rtc_clk))
+ clk_disable_unprepare(wilc->rtc_clk);
+
if (!wilc->suspend_event) {
wilc_chip_sleep_manually(wilc);
} else {
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 1e74a08..d8f3ebe 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -217,6 +217,7 @@ struct wilc {
int io_type;
s8 mac_status;
struct gpio_desc *gpio_irq;
+ struct clk *rtc_clk;
bool initialized;
int dev_irq_num;
int close;
--
2.7.4
[PATCH 1/2] staging: dt-bindings: wilc1000: add optional rtc_clk property
From: Eugen Hristev
Add bindings for optional rtc clock pin.
Signed-off-by: Eugen Hristev
---
drivers/staging/wilc1000/microchip,wilc1000,sdio.txt | 8 +++-
drivers/staging/wilc1000/microchip,wilc1000,spi.txt | 8
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
b/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
index 4f7d1c2..da52359 100644
--- a/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
+++ b/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
@@ -10,7 +10,9 @@ Required properties:
Optional:
- bus-width: Number of data lines wired up the slot. Default 1 bit.
-
+- rtc_clk : Clock connected on the rtc clock line. Must be assigned
+ a frequency with assigned-clocks property, and must be
+ connected to a clock provider.
Examples:
mmc1: mmc@fc00 {
@@ -24,6 +26,10 @@ mmc1: mmc@fc00 {
wilc_sdio@0 {
compatible = "microchip,wilc1000-sdio";
irq-gpios = < 27 0>;
+ clocks = <>;
+ clock-names = "rtc_clk";
+ assigned-clocks = <>;
+ assigned-clock-rates = <32768>;
status = "okay";
reg = <0>;
bus-width = <4>;
diff --git a/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
b/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
index 87db87b..3423693 100644
--- a/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
+++ b/drivers/staging/wilc1000/microchip,wilc1000,spi.txt
@@ -9,6 +9,10 @@ Required properties:
- reg : Chip select address of device
- irq-gpios: Connect to a host IRQ
+Optional:
+- rtc_clk : Clock connected on the rtc clock line. Must be assigned
+ a frequency with assigned-clocks property, and must be
+ connected to a clock provider.
Examples:
@@ -21,6 +25,10 @@ spi1: spi@fc018000 {
spi-max-frequency = <4800>;
reg = <0>;
irq-gpios = < 27 0>;
+ clocks = <>;
+ clock-names = "rtc_clk";
+ assigned-clocks = <>;
+ assigned-clock-rates = <32768>;
status = "okay";
};
};
--
2.7.4
Re: [PATCH v4 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
On 02.09.2019 13:49, Peter Rosin wrote: > On 2019-09-02 12:12, eugen.hris...@microchip.com wrote: >> From: Eugen Hristev >> >> Some i2c controllers have a built-in digital or analog filter. >> This is specifically required depending on the hardware PCB/board. >> Some controllers also allow specifying the maximum width of the >> spikes that can be filtered. The width length can be specified in >> nanoseconds. >> >> Signed-off-by: Eugen Hristev >> --- >> Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt >> b/Documentation/devicetree/bindings/i2c/i2c.txt >> index 44efafd..8dbff67 100644 >> --- a/Documentation/devicetree/bindings/i2c/i2c.txt >> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt >> @@ -55,6 +55,17 @@ wants to support one of the below features, it should >> adapt the bindings below. >> Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C >> specification. >> >> +- i2c-analog-filter >> +Enable analog filter for i2c lines. >> + >> +- i2c-digital-filter >> +Enable digital filter for i2c lines. >> + >> +- i2c-filter-width-ns >> +Width of spikes which can be filtered by either digital or analog >> +filters (i2c-analog-filtr or i2c-digital-filtr). This width is specified > > filtr -> filter (two instances) > > What if you want/need to have different bandwidth for the digital and analog > filters? After all, this is a generic binding... Hi Peter, For our needs, this is enough: the purpose of the filters is to avoid noise on the lines, the noise is as big as it is for the digital and for the analog filters, since we use an absolute measurement for them. So I do not know how useful it would be to make a difference. Wolfram, what do you think ? Eugen > > Cheers, > Peter > >> +in nanoseconds. >> + >> - interrupts >> interrupts used by the device. >> >> > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > >
Re: [PATCH v4 1/9] dt-bindings: i2c: at91: add new compatible
On 02.09.2019 13:44, Peter Rosin wrote: > > On 2019-09-02 12:11, eugen.hris...@microchip.com wrote: >> From: Eugen Hristev >> >> Add compatible for new Microchip SoC, sam9x60 >> >> Reviewed-by: Rob Herring >> Signed-off-by: Eugen Hristev >> --- >> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt >> b/Documentation/devicetree/bindings/i2c/i2c-at91.txt >> index b7cec17..2210f43 100644 >> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt >> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt >> @@ -3,7 +3,8 @@ I2C for Atmel platforms >> Required properties : >> - compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c", >>"atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", >> "atmel,at91sam9g10-i2c", >> - "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c" >> + "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or >> + "microchip,sam9x60-i2c" > > IIUC, this list should ideally be reformatted with one compatible per line. > > Side note; unfortunate naming with SAM9x60, when there is a preexisting 9260 > fitting the "wildcard" (AFAICT, it's not a wildcard in this case, but it sure > looks like one). > Yes, this is a separate SoC. It is named SAM9X60 and not related to old 9260 Reformatting the list would be useful perhaps in a different cosmetic patch ? > Cheers, > Peter > >> - reg: physical base address of the controller and length of memory mapped >>region. >> - interrupts: interrupt number to the cpu. >> > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > >
[PATCH v4 9/9] ARM: dts: at91: sama5d4_xplained: add digital filter for i2c
From: Eugen Hristev
Add property for digital filter for i2c0 node sama5d4_xplained
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index fdfc37d..924d949 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -49,6 +49,7 @@
};
i2c0: i2c@f8014000 {
+ i2c-digital-filter;
status = "okay";
};
--
2.7.4
[PATCH v4 8/9] ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c
From: Eugen Hristev
Add property for analog and digital filter for i2c1 and i2c2 nodes
for sama5d2_xplained
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 808e399..2083585 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -334,6 +334,9 @@
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
atmel,fifo-size = <16>;
+ i2c-analog-filter;
+ i2c-digital-filter;
+ i2c-filter-width-ns = <35>;
status = "okay";
};
};
@@ -342,6 +345,9 @@
dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_i2c1_default>;
+ i2c-analog-filter;
+ i2c-digital-filter;
+ i2c-filter-width-ns = <35>;
status = "okay";
at24@54 {
--
2.7.4
[PATCH v4 6/9] i2c: at91: add support for advanced digital filtering
From: Eugen Hristev
Add new platform data support for advanced digital filtering for i2c.
The sama5d2 and sam9x60 support this feature.
This digital filter allows the user to configure the maximum
width of the spikes that can be filtered.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 30 +++---
drivers/i2c/busses/i2c-at91.h| 5 +
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index e96360f..1f4ee7e 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -69,6 +69,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -78,6 +79,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -87,6 +89,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -96,6 +99,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -105,6 +109,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -136,6 +141,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -145,6 +151,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_alt_cmd = false,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -154,6 +161,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -163,6 +171,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index df80557..078bbde 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -43,6 +43,12 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+
+ /* enable advanced digital filter */
+ if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(dev->filter_width) &
+ AT91_TWI_FILTR_THRES_MASK));
}
/*
@@ -51,7 +57,7 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
*/
static void at91_calc_twi_clock(struct at91_twi_dev *dev)
{
- int ckdiv, cdiv, div, hold = 0;
+ int ckdiv, cdiv, div, hold = 0, filter_width = 0;
struct at91_twi_pdata *pdata = dev->pdata;
int offset = pdata->clk_offset;
int max_ckdiv = pdata->clk_max_div;
@@ -90,11 +96,29 @@ static void at91_calc_twi_clock(struct at91_twi_dev *dev)
}
}
+ if (pdata->has_adv_dig_filtr) {
+ /*
+* filter width = 0 to AT91_TWI_FILTR_THRES_MAX
+* peripheral clocks
+*/
+ filter_width = DIV_ROUND_UP(t->filter_width_ns
+ * (clk_get_rate(dev->clk) / 1000), 100);
+ if (filter_width > AT91_TWI_FILTR_THRES_MAX) {
+ dev_warn(dev->dev,
+ "Filter threshold set to its maximum value (%d
instead of %d)\n",
+ AT91_TWI_FILTR_THRES_MAX, filter_width);
+ filter_width = AT91_TWI_FILTR_THRES_MAX;
+ }
+ }
+
[PATCH v4 0/9] i2c: add support for filters
From: Eugen Hristev Hello, This series adds support for analog and digital filters for i2c controllers This series is based on the series: [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs and enhanced to add the bindings for all controllers plus an extra binding for the width of the spikes in nanoseconds. First, bindings are created for 'i2c-analog-filter' 'i2c-digital-filter' 'i2c-filter-width-ns' The support is added in the i2c core to retrieve filter width and add it to the timings structure. Next, the at91 driver is enhanced for supporting digital filter, advanced digital filter (with selectable spike width) and the analog filter. Finally the device tree for two boards are modified to make use of the new properties. This series is the result of the comments on the ML in the direction requested: to make the bindings globally available for i2c drivers. Changes in v4: - renamed i2c-ana-filter to i2c-analog-filter - renamed i2c-dig-filter to i2c-digital-filter Changes in v3: - made bindings global for i2c controllers and modified accordingly - gave up PADFCDF bit because it's a lack in datasheet - the computation on the width of the spike is based on periph clock as it is done for hold time. Changes in v2: - added device tree bindings and support for enable-ana-filt and enable-dig-filt - added the new properties to the DT for sama5d4_xplained/sama5d2_xplained Eugen Hristev (9): dt-bindings: i2c: at91: add new compatible dt-bindings: i2c: add bindings for i2c analog and digital filter i2c: add support for filter-width-ns optional property i2c: at91: add new platform support for sam9x60 i2c: at91: add support for digital filtering i2c: at91: add support for advanced digital filtering i2c: at91: add support for analog filtering ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c ARM: dts: at91: sama5d4_xplained: add digital filter for i2c Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +- Documentation/devicetree/bindings/i2c/i2c.txt | 11 + arch/arm/boot/dts/at91-sama5d2_xplained.dts| 6 +++ arch/arm/boot/dts/at91-sama5d4_xplained.dts| 1 + drivers/i2c/busses/i2c-at91-core.c | 38 + drivers/i2c/busses/i2c-at91-master.c | 49 -- drivers/i2c/busses/i2c-at91.h | 13 ++ drivers/i2c/i2c-core-base.c| 2 + include/linux/i2c.h| 2 + 9 files changed, 121 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v4 7/9] i2c: at91: add support for analog filtering
From: Eugen Hristev
Add support for analog filtering for i2c lines.
The sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 18 ++
drivers/i2c/busses/i2c-at91.h| 3 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 1f4ee7e..e13af48 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -70,6 +70,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -80,6 +81,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -90,6 +92,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -100,6 +103,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -110,6 +114,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -142,6 +147,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -152,6 +158,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -162,6 +169,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -172,6 +180,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index 078bbde..68e1ca7 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -32,6 +32,7 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
struct at91_twi_pdata *pdata = dev->pdata;
+ u32 filtr = 0;
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
@@ -42,13 +43,20 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+ filtr |= AT91_TWI_FILTR_FILT;
/* enable advanced digital filter */
if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
- (AT91_TWI_FILTR_THRES(dev->filter_width) &
- AT91_TWI_FILTR_THRES_MASK));
+ filtr |= AT91_TWI_FILTR_FILT |
+(AT91_TWI_FILTR_THRES(dev->filter_width) &
+AT91_TWI_FILTR_THRES_MASK);
+
+ /* enable analog filter */
+ if (pdata->has_ana_filtr && dev->enable_ana_filt)
+ filtr |= AT91_TWI_FILTR_PADFEN;
+
+ if (filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, filtr);
}
/*
@@ -826,6 +834,8 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
"i2c-digital-filter");
+ dev->enable_ana_filt = of_property_read_bool(pdev->dev.of_node,
+"i2c-analog-filter");
at91_calc_twi_clock(dev);
dev->adapter.algo = _twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index d7cf01e3..977a67b 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++
[PATCH v4 1/9] dt-bindings: i2c: at91: add new compatible
From: Eugen Hristev Add compatible for new Microchip SoC, sam9x60 Reviewed-by: Rob Herring Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index b7cec17..2210f43 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt @@ -3,7 +3,8 @@ I2C for Atmel platforms Required properties : - compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c", "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c", - "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c" + "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or + "microchip,sam9x60-i2c" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt number to the cpu. -- 2.7.4
[PATCH v4 5/9] i2c: at91: add support for digital filtering
From: Eugen Hristev
Add new platform data support for digital filtering for i2c.
The sama5d4, sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 9 +
drivers/i2c/busses/i2c-at91.h| 5 +
3 files changed, 23 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index caf1846..e96360f 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_unre_flag = true,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -154,6 +162,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index a3fcc35..df80557 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -31,12 +31,18 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
+ struct at91_twi_pdata *pdata = dev->pdata;
+
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_MSEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SVDIS);
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
+
+ /* enable digital filter */
+ if (pdata->has_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
}
/*
@@ -793,6 +799,9 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
}
+ dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
+"i2c-digital-filter");
+
at91_calc_twi_clock(dev);
dev->adapter.algo = _twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 499b506..c75447e 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -84,6 +84,9 @@
#defineAT91_TWI_ACR_DATAL(len) ((len) & 0xff)
#defineAT91_TWI_ACR_DIRBIT(8)
+#define AT91_TWI_FILTR 0x0044
+#define AT91_TWI_FILTR_FILTBIT(0)
+
#defineAT91_TWI_FMR0x0050 /* FIFO Mode Register */
#defineAT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
#defineAT91_TWI_FMR_TXRDYM_MASK(0x3 << 0)
@@ -108,6 +111,7 @@ struct at91_twi_pdata {
bool has_unre_flag;
bool has_alt_cmd;
bool has_hold_field;
+ bool has_dig_filtr;
struct at_dma_slave dma_slave;
};
@@ -145,6 +149,7 @@ struct at91_twi_dev {
unsigned smr;
struct i2c_client *slave;
[PATCH v4 4/9] i2c: at91: add new platform support for sam9x60
From: Eugen Hristev
Add new platform data support for the sam9x60 SoC
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 435c7d7..caf1846 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -148,6 +148,14 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
};
+static struct at91_twi_pdata sam9x60_config = {
+ .clk_max_div = 7,
+ .clk_offset = 4,
+ .has_unre_flag = true,
+ .has_alt_cmd = true,
+ .has_hold_field = true,
+};
+
static const struct of_device_id atmel_twi_dt_ids[] = {
{
.compatible = "atmel,at91rm9200-i2c",
@@ -174,6 +182,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
.compatible = "atmel,sama5d2-i2c",
.data = _config,
}, {
+ .compatible = "microchip,sam9x60-i2c",
+ .data = _config,
+ }, {
/* sentinel */
}
};
--
2.7.4
[PATCH v4 3/9] i2c: add support for filter-width-ns optional property
From: Eugen Hristev
This optional timing property specifies the width of the spikes on the i2c
lines (in ns) that can be filtered out by built-in analog or digital filters
which are embedded in some i2c controllers.
Include it in the timings structure and read it as integer property.
Signed-off-by: Eugen Hristev
---
drivers/i2c/i2c-core-base.c | 2 ++
include/linux/i2c.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index f26ed49..804197e 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1658,6 +1658,8 @@ void i2c_parse_fw_timings(struct device *dev, struct
i2c_timings *t, bool use_de
t->sda_fall_ns = t->scl_fall_ns;
device_property_read_u32(dev, "i2c-sda-hold-time-ns", >sda_hold_ns);
+
+ device_property_read_u32(dev, "i2c-filter-width-ns",
>filter_width_ns);
}
EXPORT_SYMBOL_GPL(i2c_parse_fw_timings);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fa5552c..b1e9c39 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -575,6 +575,7 @@ struct i2c_lock_operations {
* @scl_int_delay_ns: time IP core additionally needs to setup SCL in ns
* @sda_fall_ns: time SDA signal takes to fall in ns; t(f) in the I2C
specification
* @sda_hold_ns: time IP core additionally needs to hold SDA in ns
+ * @filter_width_ns: width in ns of spikes on i2c lines that the IP core can
filter out
*/
struct i2c_timings {
u32 bus_freq_hz;
@@ -583,6 +584,7 @@ struct i2c_timings {
u32 scl_int_delay_ns;
u32 sda_fall_ns;
u32 sda_hold_ns;
+ u32 filter_width_ns;
};
/**
--
2.7.4
[PATCH v4 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Eugen Hristev Some i2c controllers have a built-in digital or analog filter. This is specifically required depending on the hardware PCB/board. Some controllers also allow specifying the maximum width of the spikes that can be filtered. The width length can be specified in nanoseconds. Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index 44efafd..8dbff67 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below. Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C specification. +- i2c-analog-filter + Enable analog filter for i2c lines. + +- i2c-digital-filter + Enable digital filter for i2c lines. + +- i2c-filter-width-ns + Width of spikes which can be filtered by either digital or analog + filters (i2c-analog-filtr or i2c-digital-filtr). This width is specified + in nanoseconds. + - interrupts interrupts used by the device. -- 2.7.4
Re: [PATCH v3 5/9] i2c: at91: add support for digital filtering
On 31.08.2019 15:17, Wolfram Sang wrote: > >>> + dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node, >>> +"i2c-dig-filter"); >>> + >> >> What do you think of the idea to introduce 'flags' to struct i2c_timings >> and parse the bindings in the core, too? Then you'd have sth like: >> >> if (t->flags & I2C_TIMINGS_ANALOG_FILTER) >> >> Would that be useful for you? > > Forgot to say, we can also implement this incrementally to make sure > your patches land in 5.4 in case you are currently busy with sth else. > Hi Wolfram, Your idea looks good but I would prefer to have it as a separate enhancement patch, after this series gets in. As things are now, this series/patches do just the filtering part. We can then move all the optional 'flags' as another change. So yes, we can do this incrementally. Thanks ! Eugen > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
Re: [PATCH v3 0/9] i2c: add support for filters
On 12.07.2019 11:20, Ludovic Desroches wrote: > On Tue, Jul 09, 2019 at 03:19:26PM +0200, Eugen Hristev - M18282 wrote: >> From: Eugen Hristev >> >> Hello, >> >> This series adds support for analog and digital filters for i2c controllers >> >> This series is based on the series: >> [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs >> and enhanced to add the bindings for all controllers plus an extra binding >> for the width of the spikes in nanoseconds. >> >> First, bindings are created for >> 'i2c-ana-filter' >> 'i2c-dig-filter' >> 'i2c-filter-width-ns' >> >> The support is added in the i2c core to retrieve filter width and add it >> to the timings structure. >> Next, the at91 driver is enhanced for supporting digital filter, advanced >> digital filter (with selectable spike width) and the analog filter. >> >> Finally the device tree for two boards are modified to make use of the >> new properties. >> >> This series is the result of the comments on the ML in the direction >> requested: to make the bindings globally available for i2c drivers. >> >> Changes in v3: >> - made bindings global for i2c controllers and modified accordingly >> - gave up PADFCDF bit because it's a lack in datasheet >> - the computation on the width of the spike is based on periph clock as it >> is done for hold time. >> >> Changes in v2: >> - added device tree bindings and support for enable-ana-filt and >> enable-dig-filt >> - added the new properties to the DT for sama5d4_xplained/sama5d2_xplained >> >> Eugen Hristev (9): >>dt-bindings: i2c: at91: add new compatible >>dt-bindings: i2c: add bindings for i2c analog and digital filter >>i2c: add support for filter-width-ns optional property >>i2c: at91: add new platform support for sam9x60 >>i2c: at91: add support for digital filtering >>i2c: at91: add support for advanced digital filtering >>i2c: at91: add support for analog filtering >>ARM: dts: at91: sama5d2_xplained: add analog and digital filter for >> i2c >>ARM: dts: at91: sama5d4_xplained: add analog filter for i2c >> >> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +- >> Documentation/devicetree/bindings/i2c/i2c.txt | 11 + >> arch/arm/boot/dts/at91-sama5d2_xplained.dts| 6 +++ >> arch/arm/boot/dts/at91-sama5d4_xplained.dts| 1 + >> drivers/i2c/busses/i2c-at91-core.c | 38 + >> drivers/i2c/busses/i2c-at91-master.c | 49 >> -- >> drivers/i2c/busses/i2c-at91.h | 13 ++ >> drivers/i2c/i2c-core-base.c| 2 + >> include/linux/i2c.h| 2 + >> 9 files changed, 121 insertions(+), 4 deletions(-) > > Hi, > > I don't know if it will fit other vendors need concerning the binding > but for Microchip it sounds good. > > Acked-by: Ludovic Desroches > for the whole serie. > > Regards > > Ludovic > Hello Wolfram, What is the plan for this patch series? Thanks, Eugen
[PATCH] media: atmel: atmel-isi: fix timeout value for stop streaming
From: Alexandre Kroupski
In case of sensor malfunction, stop streaming timeout takes much longer
than expected.
This is due to conversion of time to jiffies: milliseconds multiplied
with HZ (ticks/second) gives out a value of jiffies with 10^3 greater.
We need to also divide by 10^3 to obtain the right jiffies value.
In other words FRAME_INTERVAL_MILLI_SEC must be in seconds in order to multiply
by HZ and get the right jiffies value to add to the current jiffies for the
timeout expire time.
Fixes: 195ebc43bf76 ("[media] V4L: at91: add Atmel Image Sensor Interface (ISI)
support")
Signed-off-by: Alexandre Kroupski
Reviewed-by: Eugen Hristev
---
drivers/media/platform/atmel/atmel-isi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/atmel/atmel-isi.c
b/drivers/media/platform/atmel/atmel-isi.c
index d7d94c1..428f117 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -493,7 +493,7 @@ static void stop_streaming(struct vb2_queue *vq)
spin_unlock_irq(>irqlock);
if (!isi->enable_preview_path) {
- timeout = jiffies + FRAME_INTERVAL_MILLI_SEC * HZ;
+ timeout = jiffies + (FRAME_INTERVAL_MILLI_SEC * HZ) / 1000;
/* Wait until the end of the current frame. */
while ((isi_readl(isi, ISI_STATUS) & ISI_CTRL_CDC) &&
time_before(jiffies, timeout))
--
2.7.4
Re: [PATCH 2/2] ARM: dts: at91: sama5d27_som1_ek: add mmc capabilities for SDMMC0
On 09.08.2019 09:23, Ludovic Desroches wrote:
> On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
>> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
>>> On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
From: Eugen Hristev
Add mmc capabilities for SDMMC0 for this board.
With this enabled, eMMC connected card is detected as:
mmc0: new DDR MMC card at address 0001
Signed-off-by: Eugen Hristev
>>> Acked-by: Ludovic Desroches
>>>
>>> I am interested to have the some insights about the use of sd-uhs-*
>>> properties.
>>>
>>> Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
>>> be used as the logic control input of a mux. So even if the IP claims
>>> to support UHS modes, it depends on the board.
>>>
>>> Are the sd-uhs-* properties a way to deal with this? I tend to think no
>>> as sdhci_setup_host() will set the caps depending on the content of the
>>> capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
>>> quirk or sdhci-caps/sdhci-caps-mask?
>>
>> There is "no-1-8-v" which it looks like sdhci-of-at91.c already supports:
>>
>>sdhci_at91_probe() -> sdhci_get_of_property() -> sdhci_get_property()
>>
>> if (device_property_present(dev, "no-1-8-v"))
>> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>
>
> Right, I forgot this property. Thanks.
>
> Eugen, do you see cases we can't cover with this property?
Hi,
For current requirements and driver support, this should be enough.
I noticed one thing regarding SD-Cards, if I add property sd-uhs-sdr104
the class 10 uhs1 cards are detected as SDR104 . Without this property
they are detected as DDR50. Any idea why the difference ? The controller
does not claim to have SDR104 support ? We should add it ?
Eugen
>
> Regards
>
> Ludovic
>
>>
>>>
>>> Regards
>>>
>>> Ludovic
>>>
---
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 149e539..194b3a3 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -54,6 +54,7 @@
sdmmc0: sdio-host@a000 {
bus-width = <8>;
+ mmc-ddr-3_3v;
pinctrl-names = "default";
pinctrl-0 = <_sdmmc0_default>;
status = "okay";
--
2.7.4
>>>
>>
>
[PATCH 1/2] mmc: sdhci-of-at91: add quirk for broken HS200
From: Eugen Hristev HS200 is not implemented in the driver, but the controller claims it through caps. Remove it via quirk. Without this quirk, the mmc core will try to enable hs200, which will fail, and the eMMC initialization will fail. Signed-off-by: Eugen Hristev --- drivers/mmc/host/sdhci-of-at91.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c index 57fe3b2..3a8c6d8 100644 --- a/drivers/mmc/host/sdhci-of-at91.c +++ b/drivers/mmc/host/sdhci-of-at91.c @@ -370,6 +370,9 @@ static int sdhci_at91_probe(struct platform_device *pdev) pm_runtime_set_autosuspend_delay(>dev, 50); pm_runtime_use_autosuspend(>dev); + /* HS200 is broken at this moment */ + host->quirks2 = SDHCI_QUIRK2_BROKEN_HS200; + ret = sdhci_add_host(host); if (ret) goto pm_runtime_disable; -- 2.7.4
[PATCH 2/2] ARM: dts: at91: sama5d27_som1_ek: add mmc capabilities for SDMMC0
From: Eugen Hristev
Add mmc capabilities for SDMMC0 for this board.
With this enabled, eMMC connected card is detected as:
mmc0: new DDR MMC card at address 0001
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 149e539..194b3a3 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -54,6 +54,7 @@
sdmmc0: sdio-host@a000 {
bus-width = <8>;
+ mmc-ddr-3_3v;
pinctrl-names = "default";
pinctrl-0 = <_sdmmc0_default>;
status = "okay";
--
2.7.4
Re: [v4 1/6] dt-bindings: media: Document bindings for DW MIPI CSI-2 Host
On 26.07.2019 12:50, Luis de Oliveira wrote: > Hi Sakari, > > Thank you for the review, my answers inline. > >> From: Sakari Ailus >> Date: Thu, Jul 25, 2019 at 21:02:11 >> >> Hi Luis, >> >> On Wed, Jul 10, 2019 at 10:20:55AM +, Luis de Oliveira wrote: >>> Hi Sakari, >>> >>> From: Sakari Ailus >>> Date: Tue, Jul 09, 2019 at 19:25:00 >>> Hi Luis, On Mon, Jul 08, 2019 at 03:21:50PM +, Luis de Oliveira wrote: > Hi Sakari, > > Thank you for your feedback. > I have my comments inline. > > From: Sakari Ailus > Date: Fri, Jun 28, 2019 at 15:13:26 > >> Hi Luis, >> >> Thank you for the patchset. >> >> On Tue, Jun 11, 2019 at 09:20:50PM +0200, Luis Oliveira wrote: >>> From: Luis Oliveira >>> >>> Add bindings for Synopsys DesignWare MIPI CSI-2 host. >>> >>> Signed-off-by: Luis Oliveira >>> --- >>> Changelog >>> v3-v4 >>> - remove "plat" from the block name @rob @laurent >>> - remove "phy-names" when single-entry @rob >>> - remove "snps,output-type" -> went to the driver config @laurent >>> >>> .../devicetree/bindings/media/snps,dw-csi.txt | 41 >>> ++ >>> 1 file changed, 41 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/media/snps,dw-csi.txt >>> >>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi.txt >>> b/Documentation/devicetree/bindings/media/snps,dw-csi.txt >>> new file mode 100644 >>> index 000..613b7f9 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/media/snps,dw-csi.txt >>> @@ -0,0 +1,41 @@ >>> +Synopsys DesignWare CSI-2 Host controller >>> + >>> +Description >>> +--- >>> + >>> +This HW block is used to receive image coming from an MIPI CSI-2 >>> compatible >>> +camera. >>> + >>> +Required properties: >>> +- compatible : shall be "snps,dw-csi" >>> +- reg : physical base address and size of the device >>> memory >>> + mapped registers; >>> +- interrupts : DW CSI-2 Host interrupts >>> +- phys : List of one PHY specifier (as defined in >>> + >>> Documentation/devicetree/bindings/phy/phy-bindings.txt). >>> + This PHY is a MIPI DPHY working in RX mode. >>> +- resets : Reference to a reset controller (optional) >>> + >>> +The per-board settings: >>> + - port sub-node describing a single endpoint connected to the camera >>> as >>> + described in video-interfaces.txt[1]. >> >> Which endpoint properties in video-interfaces.txt are relevant for the >> hardware? Which values may they have? >> > > Currently I'm using only two properties "data-lanes" and "bus-width", but > I have plans to add blanking info also. > I will add more info. Isn't blanking defined by what the transmitter seneds? Or do you have hardware limitations on the receiver side? >>> >>> When we use this IP in prototyping we configure blanking at the receiver >>> side. >>> Some cameras don't have blanking configuration capabilities so we >>> configure it on the RX side. >> >> I haven't come across a CSI-2 connected camera without some kind of >> blanking configuration capabilities. Even if there was one, you couldn't >> configure blanking from the receiver side. >> >> Please document that the data-lanes property is required, and which values >> are possible. >> > > Ok, I will add the data-lanes property to the Documentation. > >>> I've only heard of one such case before, and it was a very old parallel receiver. If you have a CSI-2 receiver, bus-width isn't relevant --- it's for paralle interfaces only. Please add data-lanes to required endpoint properties. >>> >>> I used bus-width property in the Synopsys IPI (Image Pixel Interface) >>> that enables direct video stream access. >>> This interface is an output that can be 16-bit or 48-bit, that's why I >>> used bus-width property. >> >> Does this device write the image data to system memory, or is it another >> device? If there's another one, then you should probably have another port >> to describe that connection. >> > > Yes, it is another. I can add that connection port also. Yes please. It is interesting for me to see how to connect the output of this device to another media device, and how to specify the bus in this situation. Thanks, Eugen > > >> -- >> Kind regards, >> >> Sakari Ailus > > Thank you, > > Luis > >
Re: [v4 2/6] media: platform: dwc: Add MIPI CSI-2 controller driver
Hello Luis, A few questions inline: On 11.06.2019 22:20, Luis Oliveira wrote: > Add the Synopsys MIPI CSI-2 controller driver. This > controller driver is divided in platform functions and core functions. > This way it serves as platform for future DesignWare drivers. > > Signed-off-by: Luis Oliveira > --- > Changelog > v3-v4 > - fix v4l2_fwnode_endpoint bad initialization @eugen > - removed extra lines and fixed coding style issues > > MAINTAINERS | 8 + > drivers/media/platform/Kconfig| 1 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/dwc/Kconfig| 19 + > drivers/media/platform/dwc/Makefile | 9 + > drivers/media/platform/dwc/dw-csi-plat.c | 475 +++ > drivers/media/platform/dwc/dw-csi-plat.h | 97 + > drivers/media/platform/dwc/dw-csi-sysfs.c | 624 > ++ > drivers/media/platform/dwc/dw-mipi-csi.c | 569 +++ > drivers/media/platform/dwc/dw-mipi-csi.h | 287 ++ > include/media/dwc/dw-mipi-csi-pltfrm.h| 104 + > 11 files changed, 2195 insertions(+) > create mode 100644 drivers/media/platform/dwc/Kconfig > create mode 100644 drivers/media/platform/dwc/Makefile > create mode 100644 drivers/media/platform/dwc/dw-csi-plat.c > create mode 100644 drivers/media/platform/dwc/dw-csi-plat.h > create mode 100644 drivers/media/platform/dwc/dw-csi-sysfs.c > create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.c > create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.h > create mode 100644 include/media/dwc/dw-mipi-csi-pltfrm.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 16a97ba..6ffe4fd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -15187,6 +15187,14 @@ S: Maintained > F: drivers/dma/dwi-axi-dmac/ > F: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt > > +SYNOPSYS DESIGNWARE MIPI DPHY CSI-2 HOST DRIVER > +M: Luis Oliveira > +L: linux-me...@vger.kernel.org > +T: git git://linuxtv.org/media_tree.git > +S: Maintained > +F: drivers/media/platform/dwc > +F: Documentation/devicetree/bindings/media/snps,dw-csi.txt > + > SYNOPSYS DESIGNWARE DMAC DRIVER > M: Viresh Kumar > R: Andy Shevchenko > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 8a19654..b6fb139 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -147,6 +147,7 @@ source "drivers/media/platform/xilinx/Kconfig" > source "drivers/media/platform/rcar-vin/Kconfig" > source "drivers/media/platform/atmel/Kconfig" > source "drivers/media/platform/sunxi/sun6i-csi/Kconfig" > +source "drivers/media/platform/dwc/Kconfig" > > config VIDEO_TI_CAL > tristate "TI CAL (Camera Adaptation Layer) driver" > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index 7cbbd92..4807caf 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -101,3 +101,5 @@ obj-y += meson/ > obj-y += cros-ec-cec/ > > obj-$(CONFIG_VIDEO_SUN6I_CSI) += sunxi/sun6i-csi/ > + > +obj-y+= dwc/ > diff --git a/drivers/media/platform/dwc/Kconfig > b/drivers/media/platform/dwc/Kconfig > new file mode 100644 > index 000..508ac21 > --- /dev/null > +++ b/drivers/media/platform/dwc/Kconfig > @@ -0,0 +1,19 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Synopsys DWC Platform drivers > +#Drivers here are currently for MIPI CSI-2 support > + > +config DWC_MIPI_CSI2_HOST > + tristate "Synopsys DesignWare CSI-2 Host Controller support" > + select VIDEO_DEV > + select VIDEO_V4L2 > + select VIDEO_V4L2_SUBDEV_API > + select V4L2_FWNODE > + help > + This selects the DesignWare MIPI CSI-2 host controller support. This > + controller gives access to control a CSI-2 receiver acting as a V4L2 > + subdevice. > + > + If you have a controller with this interface, say Y. > + > +If unsure, say N. > diff --git a/drivers/media/platform/dwc/Makefile > b/drivers/media/platform/dwc/Makefile > new file mode 100644 > index 000..057f137 > --- /dev/null > +++ b/drivers/media/platform/dwc/Makefile > @@ -0,0 +1,9 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Makefile for Synopsys DWC Platform drivers > +# > +dw-csi-objs := dw-csi-plat.o dw-mipi-csi.o > +ifeq ($(CONFIG_DWC_MIPI_TC_DPHY_GEN3),y) > + dw-csi-objs += dw-csi-sysfs.o > +endif > +obj-$(CONFIG_DWC_MIPI_CSI2_HOST) += dw-csi.o > diff --git a/drivers/media/platform/dwc/dw-csi-plat.c > b/drivers/media/platform/dwc/dw-csi-plat.c > new file mode 100644 > index 000..9828d55 > --- /dev/null > +++ b/drivers/media/platform/dwc/dw-csi-plat.c > @@ -0,0 +1,475 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2018-2019
Re: [v4 1/6] dt-bindings: media: Document bindings for DW MIPI CSI-2 Host
On 09.07.2019 20:08, Luis de Oliveira wrote:
>
> Hi Eugen,
>
>
> From: eugen.hris...@microchip.com
> Date: Tue, Jul 09, 2019 at 15:33:50
>
>>
>>
>> On 11.06.2019 22:20, Luis Oliveira wrote:
>>> From: Luis Oliveira
>>>
>>> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
>>>
>>> Signed-off-by: Luis Oliveira
>>> ---
>>> Changelog
>>> v3-v4
>>> - remove "plat" from the block name @rob @laurent
>>> - remove "phy-names" when single-entry @rob
>>> - remove "snps,output-type" -> went to the driver config @laurent
>>>
>>>.../devicetree/bindings/media/snps,dw-csi.txt | 41
>>> ++
>>>1 file changed, 41 insertions(+)
>>>create mode 100644
>>> Documentation/devicetree/bindings/media/snps,dw-csi.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi.txt
>>> b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
>>> new file mode 100644
>>> index 000..613b7f9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
>>> @@ -0,0 +1,41 @@
>>> +Synopsys DesignWare CSI-2 Host controller
>>> +
>>> +Description
>>> +---
>>> +
>>> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
>>> +camera.
>>> +
>>> +Required properties:
>>> +- compatible : shall be "snps,dw-csi"
>>> +- reg : physical base address and size of the device
>>> memory
>>> + mapped registers;
>>> +- interrupts : DW CSI-2 Host interrupts
>>> +- phys : List of one PHY specifier (as defined in
>>> +
>>> Documentation/devicetree/bindings/phy/phy-bindings.txt).
>>> + This PHY is a MIPI DPHY working in RX mode.
>>> +- resets : Reference to a reset controller (optional)
>>> +
>>> +The per-board settings:
>>> + - port sub-node describing a single endpoint connected to the camera as
>>> + described in video-interfaces.txt[1].
>>> +
>>> +Example:
>>> +
>>> + csi2: csi2@3000 {
>>> + compatible = "snps,dw-csi";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = < 0x03000 0x7FF>;
>>> + phys = <_dphy_rx>;
>>> + resets = <_rst 1>;
>>> + interrupts = <2>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> + csi_ep1: endpoint {
>>> + remote-endpoint = <_1>;
>>> + data-lanes = <1 2>;
>>> + };
>>
>> Hello Luis,
>>
>> Which is the output port (endpoint) : how to connect the output of
>> csi2host to another node ?
>> I mean, the second port of this block, or, how is the data taken from
>> csi2host ?
>>
>
> I understand your question, I think you guessed this is not the complete
> pipeline (I have a top driver that interacts with this one).
> I was not planning to submit it, do you think I should?
Yes please, you can have the patch with subject DO NOT MERGE if you do
not want that patch to be included in the kernel and just for reference.
but it would help me in understanding your setup
Thanks !
>
> The behavior is very similar with this one
> ./drivers/media/platform/exynos4-is/media-dev.c
>
>
>> Thanks,
>>
>> Eugen
>>
>>> + };
>>> + };
>>>
>
> Thanks,
> Luis
>
Re: [v4 1/6] dt-bindings: media: Document bindings for DW MIPI CSI-2 Host
On 11.06.2019 22:20, Luis Oliveira wrote:
> From: Luis Oliveira
>
> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
>
> Signed-off-by: Luis Oliveira
> ---
> Changelog
> v3-v4
> - remove "plat" from the block name @rob @laurent
> - remove "phy-names" when single-entry @rob
> - remove "snps,output-type" -> went to the driver config @laurent
>
> .../devicetree/bindings/media/snps,dw-csi.txt | 41
> ++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/snps,dw-csi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> new file mode 100644
> index 000..613b7f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> @@ -0,0 +1,41 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +---
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.
> +
> +Required properties:
> +- compatible : shall be "snps,dw-csi"
> +- reg: physical base address and size of the device
> memory
> + mapped registers;
> +- interrupts : DW CSI-2 Host interrupts
> +- phys : List of one PHY specifier (as defined in
> +
> Documentation/devicetree/bindings/phy/phy-bindings.txt).
> + This PHY is a MIPI DPHY working in RX mode.
> +- resets : Reference to a reset controller (optional)
> +
> +The per-board settings:
> + - port sub-node describing a single endpoint connected to the camera as
> + described in video-interfaces.txt[1].
> +
> +Example:
> +
> + csi2: csi2@3000 {
> + compatible = "snps,dw-csi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = < 0x03000 0x7FF>;
> + phys = <_dphy_rx>;
> + resets = <_rst 1>;
> + interrupts = <2>;
> +
> + port@0 {
> + reg = <0>;
> + csi_ep1: endpoint {
> + remote-endpoint = <_1>;
> + data-lanes = <1 2>;
> + };
Hello Luis,
Which is the output port (endpoint) : how to connect the output of
csi2host to another node ?
I mean, the second port of this block, or, how is the data taken from
csi2host ?
Thanks,
Eugen
> + };
> + };
>
[PATCH v3 5/9] i2c: at91: add support for digital filtering
From: Eugen Hristev
Add new platform data support for digital filtering for i2c.
The sama5d4, sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 9 +
drivers/i2c/busses/i2c-at91.h| 5 +
3 files changed, 23 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index a663a7a..62610af 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -68,6 +68,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_unre_flag = true,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -76,6 +77,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -84,6 +86,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -92,6 +95,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -100,6 +104,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -130,6 +135,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = false,
+ .has_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -138,6 +144,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_unre_flag = false,
.has_alt_cmd = false,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -146,6 +153,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -154,6 +162,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_unre_flag = true,
.has_alt_cmd = true,
.has_hold_field = true,
+ .has_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index e87232f..099161a 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -31,12 +31,18 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
+ struct at91_twi_pdata *pdata = dev->pdata;
+
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_MSEN);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SVDIS);
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
+
+ /* enable digital filter */
+ if (pdata->has_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
}
/*
@@ -792,6 +798,9 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
}
+ dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
+"i2c-dig-filter");
+
at91_calc_twi_clock(dev);
dev->adapter.algo = _twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 499b506..c75447e 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -84,6 +84,9 @@
#defineAT91_TWI_ACR_DATAL(len) ((len) & 0xff)
#defineAT91_TWI_ACR_DIRBIT(8)
+#define AT91_TWI_FILTR 0x0044
+#define AT91_TWI_FILTR_FILTBIT(0)
+
#defineAT91_TWI_FMR0x0050 /* FIFO Mode Register */
#defineAT91_TWI_FMR_TXRDYM(mode) (((mode) & 0x3) << 0)
#defineAT91_TWI_FMR_TXRDYM_MASK(0x3 << 0)
@@ -108,6 +111,7 @@ struct at91_twi_pdata {
bool has_unre_flag;
bool has_alt_cmd;
bool has_hold_field;
+ bool has_dig_filtr;
struct at_dma_slave dma_slave;
};
@@ -145,6 +149,7 @@ struct at91_twi_dev {
unsigned smr;
struct i2c_client *slave;
#endif
+
[PATCH v3 8/9] ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c
From: Eugen Hristev
Add property for analog and digital filter for i2c1 and i2c2 nodes
for sama5d2_xplained
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 808e399..965326c 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -334,6 +334,9 @@
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
atmel,fifo-size = <16>;
+ i2c-ana-filter;
+ i2c-dig-filter;
+ i2c-filter-width-ns = <35>;
status = "okay";
};
};
@@ -342,6 +345,9 @@
dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_i2c1_default>;
+ i2c-ana-filter;
+ i2c-dig-filter;
+ i2c-filter-width-ns = <35>;
status = "okay";
at24@54 {
--
2.7.4
[PATCH v3 9/9] ARM: dts: at91: sama5d4_xplained: add digital filter for i2c
From: Eugen Hristev
Add property for digital filter for i2c0 node sama5d4_xplained
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index fdfc37d..298113c 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -49,6 +49,7 @@
};
i2c0: i2c@f8014000 {
+ i2c-dig-filter;
status = "okay";
};
--
2.7.4
[PATCH v3 3/9] i2c: add support for filter-width-ns optional property
From: Eugen Hristev
This optional timing property specifies the width of the spikes on the i2c
lines (in ns) that can be filtered out by built-in analog or digital filters
which are embedded in some i2c controllers.
Include it in the timings structure and read it as integer property.
Signed-off-by: Eugen Hristev
---
drivers/i2c/i2c-core-base.c | 2 ++
include/linux/i2c.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 9e43508..73d1c62 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1658,6 +1658,8 @@ void i2c_parse_fw_timings(struct device *dev, struct
i2c_timings *t, bool use_de
t->sda_fall_ns = t->scl_fall_ns;
device_property_read_u32(dev, "i2c-sda-hold-time-ns", >sda_hold_ns);
+
+ device_property_read_u32(dev, "i2c-filter-width-ns",
>filter_width_ns);
}
EXPORT_SYMBOL_GPL(i2c_parse_fw_timings);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 1308126..dfb6525 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -563,6 +563,7 @@ struct i2c_lock_operations {
* @scl_int_delay_ns: time IP core additionally needs to setup SCL in ns
* @sda_fall_ns: time SDA signal takes to fall in ns; t(f) in the I2C
specification
* @sda_hold_ns: time IP core additionally needs to hold SDA in ns
+ * @filter_width_ns: width in ns of spikes on i2c lines that the IP core can
filter out
*/
struct i2c_timings {
u32 bus_freq_hz;
@@ -571,6 +572,7 @@ struct i2c_timings {
u32 scl_int_delay_ns;
u32 sda_fall_ns;
u32 sda_hold_ns;
+ u32 filter_width_ns;
};
/**
--
2.7.4
[PATCH v3 7/9] i2c: at91: add support for analog filtering
From: Eugen Hristev
Add support for analog filtering for i2c lines.
The sama5d2 and sam9x60 support this feature.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 18 ++
drivers/i2c/busses/i2c-at91.h| 3 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 3bbe37c..d2840ba 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -70,6 +70,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -80,6 +81,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -90,6 +92,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -100,6 +103,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -110,6 +114,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -142,6 +147,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_hold_field = false,
.has_dig_filtr = false,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -152,6 +158,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = false,
+ .has_ana_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -162,6 +169,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -172,6 +180,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_hold_field = true,
.has_dig_filtr = true,
.has_adv_dig_filtr = true,
+ .has_ana_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index 344fd26..4b89610 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -32,6 +32,7 @@
void at91_init_twi_bus_master(struct at91_twi_dev *dev)
{
struct at91_twi_pdata *pdata = dev->pdata;
+ u32 filtr = 0;
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
@@ -42,13 +43,20 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+ filtr |= AT91_TWI_FILTR_FILT;
/* enable advanced digital filter */
if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
- at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
- (AT91_TWI_FILTR_THRES(dev->filter_width) &
- AT91_TWI_FILTR_THRES_MASK));
+ filtr |= AT91_TWI_FILTR_FILT |
+(AT91_TWI_FILTR_THRES(dev->filter_width) &
+AT91_TWI_FILTR_THRES_MASK);
+
+ /* enable analog filter */
+ if (pdata->has_ana_filtr && dev->enable_ana_filt)
+ filtr |= AT91_TWI_FILTR_PADFEN;
+
+ if (filtr)
+ at91_twi_write(dev, AT91_TWI_FILTR, filtr);
}
/*
@@ -825,6 +833,8 @@ int at91_twi_probe_master(struct platform_device *pdev,
dev->enable_dig_filt = of_property_read_bool(pdev->dev.of_node,
"i2c-dig-filter");
+ dev->enable_ana_filt = of_property_read_bool(pdev->dev.of_node,
+"i2c-ana-filter");
at91_calc_twi_clock(dev);
dev->adapter.algo = _twi_algorithm;
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index d7cf01e3..977a67b 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++
[PATCH v3 6/9] i2c: at91: add support for advanced digital filtering
From: Eugen Hristev
Add new platform data support for advanced digital filtering for i2c.
The sama5d2 and sam9x60 support this feature.
This digital filter allows the user to configure the maximum
width of the spikes that can be filtered.
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 9 +
drivers/i2c/busses/i2c-at91-master.c | 30 +++---
drivers/i2c/busses/i2c-at91.h| 5 +
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 62610af..3bbe37c 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -69,6 +69,7 @@ static struct at91_twi_pdata at91rm9200_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9261_config = {
@@ -78,6 +79,7 @@ static struct at91_twi_pdata at91sam9261_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9260_config = {
@@ -87,6 +89,7 @@ static struct at91_twi_pdata at91sam9260_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g20_config = {
@@ -96,6 +99,7 @@ static struct at91_twi_pdata at91sam9g20_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata at91sam9g10_config = {
@@ -105,6 +109,7 @@ static struct at91_twi_pdata at91sam9g10_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static const struct platform_device_id at91_twi_devtypes[] = {
@@ -136,6 +141,7 @@ static struct at91_twi_pdata at91sam9x5_config = {
.has_alt_cmd = false,
.has_hold_field = false,
.has_dig_filtr = false,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d4_config = {
@@ -145,6 +151,7 @@ static struct at91_twi_pdata sama5d4_config = {
.has_alt_cmd = false,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = false,
};
static struct at91_twi_pdata sama5d2_config = {
@@ -154,6 +161,7 @@ static struct at91_twi_pdata sama5d2_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static struct at91_twi_pdata sam9x60_config = {
@@ -163,6 +171,7 @@ static struct at91_twi_pdata sam9x60_config = {
.has_alt_cmd = true,
.has_hold_field = true,
.has_dig_filtr = true,
+ .has_adv_dig_filtr = true,
};
static const struct of_device_id atmel_twi_dt_ids[] = {
diff --git a/drivers/i2c/busses/i2c-at91-master.c
b/drivers/i2c/busses/i2c-at91-master.c
index 099161a..344fd26 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -43,6 +43,12 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
/* enable digital filter */
if (pdata->has_dig_filtr && dev->enable_dig_filt)
at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT);
+
+ /* enable advanced digital filter */
+ if (pdata->has_adv_dig_filtr && dev->enable_dig_filt)
+ at91_twi_write(dev, AT91_TWI_FILTR, AT91_TWI_FILTR_FILT |
+ (AT91_TWI_FILTR_THRES(dev->filter_width) &
+ AT91_TWI_FILTR_THRES_MASK));
}
/*
@@ -51,7 +57,7 @@ void at91_init_twi_bus_master(struct at91_twi_dev *dev)
*/
static void at91_calc_twi_clock(struct at91_twi_dev *dev)
{
- int ckdiv, cdiv, div, hold = 0;
+ int ckdiv, cdiv, div, hold = 0, filter_width = 0;
struct at91_twi_pdata *pdata = dev->pdata;
int offset = pdata->clk_offset;
int max_ckdiv = pdata->clk_max_div;
@@ -90,11 +96,29 @@ static void at91_calc_twi_clock(struct at91_twi_dev *dev)
}
}
+ if (pdata->has_adv_dig_filtr) {
+ /*
+* filter width = 0 to AT91_TWI_FILTR_THRES_MAX
+* peripheral clocks
+*/
+ filter_width = DIV_ROUND_UP(t->filter_width_ns
+ * (clk_get_rate(dev->clk) / 1000), 100);
+ if (filter_width > AT91_TWI_FILTR_THRES_MAX) {
+ dev_warn(dev->dev,
+ "Filter threshold set to its maximum value (%d
instead of %d)\n",
+ AT91_TWI_FILTR_THRES_MAX, filter_width);
+ filter_width = AT91_TWI_FILTR_THRES_MAX;
+ }
+ }
+
[PATCH v3 4/9] i2c: at91: add new platform support for sam9x60
From: Eugen Hristev
Add new platform data support for the sam9x60 SoC
Signed-off-by: Eugen Hristev
---
drivers/i2c/busses/i2c-at91-core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91-core.c
b/drivers/i2c/busses/i2c-at91-core.c
index 8d55cdd..a663a7a 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -148,6 +148,14 @@ static struct at91_twi_pdata sama5d2_config = {
.has_hold_field = true,
};
+static struct at91_twi_pdata sam9x60_config = {
+ .clk_max_div = 7,
+ .clk_offset = 4,
+ .has_unre_flag = true,
+ .has_alt_cmd = true,
+ .has_hold_field = true,
+};
+
static const struct of_device_id atmel_twi_dt_ids[] = {
{
.compatible = "atmel,at91rm9200-i2c",
@@ -174,6 +182,9 @@ static const struct of_device_id atmel_twi_dt_ids[] = {
.compatible = "atmel,sama5d2-i2c",
.data = _config,
}, {
+ .compatible = "microchip,sam9x60-i2c",
+ .data = _config,
+ }, {
/* sentinel */
}
};
--
2.7.4
[PATCH v3 1/9] dt-bindings: i2c: at91: add new compatible
From: Eugen Hristev Add compatible for new Microchip SoC, sam9x60 Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index b7cec17..2210f43 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt @@ -3,7 +3,8 @@ I2C for Atmel platforms Required properties : - compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c", "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c", - "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c" + "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or + "microchip,sam9x60-i2c" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt number to the cpu. -- 2.7.4
[PATCH v3 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Eugen Hristev Some i2c controllers have a built-in digital or analog filter. This is specifically required depending on the hardware PCB/board. Some controllers also allow specifying the maximum width of the spikes that can be filtered. The width length can be specified in nanoseconds. Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index 44efafd..a2d31aa 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below. Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C specification. +- i2c-ana-filter + Enable analog filter for i2c lines. + +- i2c-dig-filter + Enable digital filter for i2c lines. + +- i2c-filter-width-ns + Width of spikes which can be filtered by either digital or analog + filters (i2c-ana-filtr or i2c-dig-filtr). This width is specified + in nanoseconds. + - interrupts interrupts used by the device. -- 2.7.4
[PATCH v3 0/9] i2c: add support for filters
From: Eugen Hristev Hello, This series adds support for analog and digital filters for i2c controllers This series is based on the series: [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs and enhanced to add the bindings for all controllers plus an extra binding for the width of the spikes in nanoseconds. First, bindings are created for 'i2c-ana-filter' 'i2c-dig-filter' 'i2c-filter-width-ns' The support is added in the i2c core to retrieve filter width and add it to the timings structure. Next, the at91 driver is enhanced for supporting digital filter, advanced digital filter (with selectable spike width) and the analog filter. Finally the device tree for two boards are modified to make use of the new properties. This series is the result of the comments on the ML in the direction requested: to make the bindings globally available for i2c drivers. Changes in v3: - made bindings global for i2c controllers and modified accordingly - gave up PADFCDF bit because it's a lack in datasheet - the computation on the width of the spike is based on periph clock as it is done for hold time. Changes in v2: - added device tree bindings and support for enable-ana-filt and enable-dig-filt - added the new properties to the DT for sama5d4_xplained/sama5d2_xplained Eugen Hristev (9): dt-bindings: i2c: at91: add new compatible dt-bindings: i2c: add bindings for i2c analog and digital filter i2c: add support for filter-width-ns optional property i2c: at91: add new platform support for sam9x60 i2c: at91: add support for digital filtering i2c: at91: add support for advanced digital filtering i2c: at91: add support for analog filtering ARM: dts: at91: sama5d2_xplained: add analog and digital filter for i2c ARM: dts: at91: sama5d4_xplained: add analog filter for i2c Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 +- Documentation/devicetree/bindings/i2c/i2c.txt | 11 + arch/arm/boot/dts/at91-sama5d2_xplained.dts| 6 +++ arch/arm/boot/dts/at91-sama5d4_xplained.dts| 1 + drivers/i2c/busses/i2c-at91-core.c | 38 + drivers/i2c/busses/i2c-at91-master.c | 49 -- drivers/i2c/busses/i2c-at91.h | 13 ++ drivers/i2c/i2c-core-base.c| 2 + include/linux/i2c.h| 2 + 9 files changed, 121 insertions(+), 4 deletions(-) -- 2.7.4
