Re: [PATCH v2 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes

[maitysanchayan]

On 16-11-21 15:22:09, Stefan Agner wrote:
> On 2016-11-20 21:54, Sanchayan Maity wrote:
> > Code cleanup for improving code readability and error path fixes
> > and cleanup removing use of devm_kfree.
> 
> Two things in one, not very nice. Especially the dma_free_coherent is
> really a bug and the other is a cleanup. Can you make a separate patch
> for the bug?
> 
> As for the cleanup, I don't like the one line conditions too, but I
> don't think it is worth a patch. At least the TX path should be solved
> with my suggestion in patch 2.

Agreed.

- Sanchayan.

> 
> --
> Stefan
> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 22 --
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index 08882f7..2987a16 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -226,8 +226,10 @@ static void dspi_rx_dma_callback(void *arg)
> > if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> > for (i = 0; i < dma->curr_xfer_len; i++) {
> > d = dspi->dma->rx_dma_buf[i];
> > -   rx_word ? (*(u16 *)dspi->rx = d) :
> > -   (*(u8 *)dspi->rx = d);
> > +   if (rx_word)
> > +   *(u16 *)dspi->rx = d;
> > +   else
> > +   *(u8 *)dspi->rx = d;
> > dspi->rx += rx_word + 1;
> > }
> > }
> > @@ -247,14 +249,20 @@ static int dspi_next_xfer_dma_submit(struct
> > fsl_dspi *dspi)
> > tx_word = is_double_byte_mode(dspi);
> >  
> > for (i = 0; i < dma->curr_xfer_len - 1; i++) {
> > -   val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > +   if (tx_word)
> > +   val = *(u16 *) dspi->tx;
> > +   else
> > +   val = *(u8 *) dspi->tx;
> > dspi->dma->tx_dma_buf[i] =
> > SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
> > dspi->tx += tx_word + 1;
> > }
> >  
> > -   val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > +   if (tx_word)
> > +   val = *(u16 *) dspi->tx;
> > +   else
> > +   val = *(u8 *) dspi->tx;
> > dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0);
> > @@ -430,9 +438,11 @@ static int dspi_request_dma(struct fsl_dspi
> > *dspi, phys_addr_t phy_addr)
> > return 0;
> >  
> >  err_slave_config:
> > -   devm_kfree(dev, dma->rx_dma_buf);
> > +   dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
> > +   dma->rx_dma_buf, dma->rx_dma_phys);
> >  err_rx_dma_buf:
> > -   devm_kfree(dev, dma->tx_dma_buf);
> > +   dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
> > +   dma->tx_dma_buf, dma->tx_dma_phys);
> >  err_tx_dma_buf:
> > dma_release_channel(dma->chan_tx);
> >  err_tx_channel:

Re: [PATCH v2 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes

[maitysanchayan]

On 16-11-21 15:22:09, Stefan Agner wrote:
> On 2016-11-20 21:54, Sanchayan Maity wrote:
> > Code cleanup for improving code readability and error path fixes
> > and cleanup removing use of devm_kfree.
> 
> Two things in one, not very nice. Especially the dma_free_coherent is
> really a bug and the other is a cleanup. Can you make a separate patch
> for the bug?
> 
> As for the cleanup, I don't like the one line conditions too, but I
> don't think it is worth a patch. At least the TX path should be solved
> with my suggestion in patch 2.

Agreed.

- Sanchayan.

> 
> --
> Stefan
> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 22 --
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index 08882f7..2987a16 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -226,8 +226,10 @@ static void dspi_rx_dma_callback(void *arg)
> > if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> > for (i = 0; i < dma->curr_xfer_len; i++) {
> > d = dspi->dma->rx_dma_buf[i];
> > -   rx_word ? (*(u16 *)dspi->rx = d) :
> > -   (*(u8 *)dspi->rx = d);
> > +   if (rx_word)
> > +   *(u16 *)dspi->rx = d;
> > +   else
> > +   *(u8 *)dspi->rx = d;
> > dspi->rx += rx_word + 1;
> > }
> > }
> > @@ -247,14 +249,20 @@ static int dspi_next_xfer_dma_submit(struct
> > fsl_dspi *dspi)
> > tx_word = is_double_byte_mode(dspi);
> >  
> > for (i = 0; i < dma->curr_xfer_len - 1; i++) {
> > -   val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > +   if (tx_word)
> > +   val = *(u16 *) dspi->tx;
> > +   else
> > +   val = *(u8 *) dspi->tx;
> > dspi->dma->tx_dma_buf[i] =
> > SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
> > dspi->tx += tx_word + 1;
> > }
> >  
> > -   val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > +   if (tx_word)
> > +   val = *(u16 *) dspi->tx;
> > +   else
> > +   val = *(u8 *) dspi->tx;
> > dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0);
> > @@ -430,9 +438,11 @@ static int dspi_request_dma(struct fsl_dspi
> > *dspi, phys_addr_t phy_addr)
> > return 0;
> >  
> >  err_slave_config:
> > -   devm_kfree(dev, dma->rx_dma_buf);
> > +   dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
> > +   dma->rx_dma_buf, dma->rx_dma_phys);
> >  err_rx_dma_buf:
> > -   devm_kfree(dev, dma->tx_dma_buf);
> > +   dma_free_coherent(dev, DSPI_DMA_BUFSIZE,
> > +   dma->tx_dma_buf, dma->tx_dma_phys);
> >  err_tx_dma_buf:
> > dma_release_channel(dma->chan_tx);
> >  err_tx_channel:

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix continuous selection format

[maitysanchayan]

On 16-11-21 15:15:41, Stefan Agner wrote:
> On 2016-11-20 21:54, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..41422cd 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -261,6 +261,8 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> > dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0);
> > +   if (!dspi->cs_change)
> > +   dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
> > dspi->tx += tx_word + 1;
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> 
> Other transfer mode use:
> 
> if ((dspi->cs_change) && (!dspi->len))  
>
> dspi_pushr &= ~SPI_PUSHR_CONT;
> 
> which indicates that they only clear SPI_PUSHR_CONT at the very end of a
> transfer... The DMA code currently deselects after every DMA transfer if
> dspi->cs_change is set.
> 
> Maybe we should use the helper dspi_data_to_pushr to fill the DMA buffer
> and _clear_ SPI_PUSHR_CONT if necessary like the other transfer modes
> do... Then we can use the for loop to fill the complete buffer and get
> rid of some code dupplication.
> 
> I see that dspi_data_to_pushr does move len too, which we did not in the
> DMA case. dspi->len gets incremented only on successful DMA transfer in
> dspi_dma_xfer. However, I wonder if that is not even a bug: We increment
> dspi->tx always, but len only on success. This makes len go off sync
> with regards to the tx pointer which does not help anybody. So lets get
> rid of the update code in dspi_dma_xfer
> 

Thanks for the feedback. Using dspi_data_to_pushr really cleans up that
tx path very nicely. Why didn't I see it. Will send a follow up patch
soon after testing again.

- Sanchayan.

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix continuous selection format

[maitysanchayan]

On 16-11-21 15:15:41, Stefan Agner wrote:
> On 2016-11-20 21:54, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..41422cd 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -261,6 +261,8 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> > dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > SPI_PUSHR_PCS(dspi->cs) |
> > SPI_PUSHR_CTAS(0);
> > +   if (!dspi->cs_change)
> > +   dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
> > dspi->tx += tx_word + 1;
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> 
> Other transfer mode use:
> 
> if ((dspi->cs_change) && (!dspi->len))  
>
> dspi_pushr &= ~SPI_PUSHR_CONT;
> 
> which indicates that they only clear SPI_PUSHR_CONT at the very end of a
> transfer... The DMA code currently deselects after every DMA transfer if
> dspi->cs_change is set.
> 
> Maybe we should use the helper dspi_data_to_pushr to fill the DMA buffer
> and _clear_ SPI_PUSHR_CONT if necessary like the other transfer modes
> do... Then we can use the for loop to fill the complete buffer and get
> rid of some code dupplication.
> 
> I see that dspi_data_to_pushr does move len too, which we did not in the
> DMA case. dspi->len gets incremented only on successful DMA transfer in
> dspi_dma_xfer. However, I wonder if that is not even a bug: We increment
> dspi->tx always, but len only on success. This makes len go off sync
> with regards to the tx pointer which does not help anybody. So lets get
> rid of the update code in dspi_dma_xfer
> 

Thanks for the feedback. Using dspi_data_to_pushr really cleans up that
tx path very nicely. Why didn't I see it. Will send a follow up patch
soon after testing again.

- Sanchayan.

Re: [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE

[maitysanchayan]

Hello Mark,

On 16-11-22 00:44:30, maitysancha...@gmail.com wrote:
> Hello Mark,
> 
> On 16-11-21 19:18:47, Mark Brown wrote:
> > On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > > Current DMA implementation had a bug where the DMA transfer would
> > > exit the loop in dspi_transfer_one_message after the completion of
> > > a single transfer. This results in a multi message transfer submitted
> > > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
> > 
> > Please don't resend already applied patches.  If there are any changes
> > needed please send incremental changes on top of what's already applied.
> 
> This is not a resend of an applied patch. The whole series applies on
> top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
> incremental changes
> 
Sorry. I take that back. I now see you applied the patch and I got the applied
mail after I replied.

- Sanchayan.

Re: [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE

[maitysanchayan]

Hello Mark,

On 16-11-22 00:44:30, maitysancha...@gmail.com wrote:
> Hello Mark,
> 
> On 16-11-21 19:18:47, Mark Brown wrote:
> > On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > > Current DMA implementation had a bug where the DMA transfer would
> > > exit the loop in dspi_transfer_one_message after the completion of
> > > a single transfer. This results in a multi message transfer submitted
> > > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
> > 
> > Please don't resend already applied patches.  If there are any changes
> > needed please send incremental changes on top of what's already applied.
> 
> This is not a resend of an applied patch. The whole series applies on
> top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
> incremental changes
> 
Sorry. I take that back. I now see you applied the patch and I got the applied
mail after I replied.

- Sanchayan.

Re: [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE

[maitysanchayan]

Hello Mark,

On 16-11-21 19:18:47, Mark Brown wrote:
> On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > Current DMA implementation had a bug where the DMA transfer would
> > exit the loop in dspi_transfer_one_message after the completion of
> > a single transfer. This results in a multi message transfer submitted
> > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
> 
> Please don't resend already applied patches.  If there are any changes
> needed please send incremental changes on top of what's already applied.

This is not a resend of an applied patch. The whole series applies on
top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
incremental changes

- Sanchaya.

Re: [PATCH v2 1/4] spi: spi-fsl-dspi: Fix SPI transfer issue when using multiple SPI_IOC_MESSAGE

[maitysanchayan]

Hello Mark,

On 16-11-21 19:18:47, Mark Brown wrote:
> On Mon, Nov 21, 2016 at 11:24:01AM +0530, Sanchayan Maity wrote:
> > Current DMA implementation had a bug where the DMA transfer would
> > exit the loop in dspi_transfer_one_message after the completion of
> > a single transfer. This results in a multi message transfer submitted
> > with SPI_IOC_MESSAGE to terminate incorrectly without an error.
> 
> Please don't resend already applied patches.  If there are any changes
> needed please send incremental changes on top of what's already applied.

This is not a resend of an applied patch. The whole series applies on
top of your topic/fsl-dspi branch and has fixes for the SPI DMA as
incremental changes

- Sanchaya.

Re: [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup

[maitysanchayan]

On 16-11-17 17:03:19, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Currently dmaengine_prep_slave_single was being called with length
> > set to the complete DMA buffer size. This resulted in unwanted bytes
> > being transferred to the SPI register leading to clock and MOSI lines
> > having unwanted data even after chip select got deasserted and the
> > required bytes having been transferred.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..aee8c88 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> > dma->tx_dma_phys,
> > -   DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> > +   dma->curr_xfer_len *
> > +   DMA_SLAVE_BUSWIDTH_4_BYTES /
> > +   (tx_word ? 2 : 1),
> > +   DMA_MEM_TO_DEV,
> 
> Hm, this is getting ridiculous, I think we convert curr_xfer_len from
> bytes to DMA transfers in almost every use.
> 
> Can we make it be transfer length in actual 4 byte transfers? We then
> probably have to convert it to bytes once to subtract from
> curr_remaining_bytes, but I think it would simplify code overall...

Will the below be acceptable fix?

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 41422cd..db7f091 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -217,15 +217,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
-   int i, len;
+   int i;
u16 d;
 
rx_word = is_double_byte_mode(dspi);
 
-   len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
-   for (i = 0; i < len; i++) {
+   for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +240,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
*dspi)
struct device *dev = >pdev->dev;
int time_left;
int tx_word;
-   int i, len;
+   int i;
u16 val;
 
tx_word = is_double_byte_mode(dspi);
 
-   len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
-   for (i = 0; i < len - 1; i++) {
+   for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -267,7 +263,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
 
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
-   DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+   dma->curr_xfer_len *
+   DMA_SLAVE_BUSWIDTH_4_BYTES,
+   DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -283,7 +281,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
 
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
-   DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+   dma->curr_xfer_len *
+   DMA_SLAVE_BUSWIDTH_4_BYTES,
+   DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -330,17 +330,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = >pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
-   int tx_word;
+   int tx_word = 1;
int ret = 0;
 
-   tx_word = is_double_byte_mode(dspi);
+   if (is_double_byte_mode(dspi))
+   tx_word = 2;
curr_remaining_bytes = dspi->len;
+   bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer 

Re: [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup

[maitysanchayan]

On 16-11-17 17:03:19, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Currently dmaengine_prep_slave_single was being called with length
> > set to the complete DMA buffer size. This resulted in unwanted bytes
> > being transferred to the SPI register leading to clock and MOSI lines
> > having unwanted data even after chip select got deasserted and the
> > required bytes having been transferred.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..aee8c88 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> > dma->tx_dma_phys,
> > -   DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> > +   dma->curr_xfer_len *
> > +   DMA_SLAVE_BUSWIDTH_4_BYTES /
> > +   (tx_word ? 2 : 1),
> > +   DMA_MEM_TO_DEV,
> 
> Hm, this is getting ridiculous, I think we convert curr_xfer_len from
> bytes to DMA transfers in almost every use.
> 
> Can we make it be transfer length in actual 4 byte transfers? We then
> probably have to convert it to bytes once to subtract from
> curr_remaining_bytes, but I think it would simplify code overall...

Will the below be acceptable fix?

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 41422cd..db7f091 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -217,15 +217,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
-   int i, len;
+   int i;
u16 d;
 
rx_word = is_double_byte_mode(dspi);
 
-   len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
-   for (i = 0; i < len; i++) {
+   for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +240,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
*dspi)
struct device *dev = >pdev->dev;
int time_left;
int tx_word;
-   int i, len;
+   int i;
u16 val;
 
tx_word = is_double_byte_mode(dspi);
 
-   len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
-   for (i = 0; i < len - 1; i++) {
+   for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -267,7 +263,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
 
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
-   DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+   dma->curr_xfer_len *
+   DMA_SLAVE_BUSWIDTH_4_BYTES,
+   DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -283,7 +281,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
 
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
-   DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+   dma->curr_xfer_len *
+   DMA_SLAVE_BUSWIDTH_4_BYTES,
+   DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -330,17 +330,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = >pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
-   int tx_word;
+   int tx_word = 1;
int ret = 0;
 
-   tx_word = is_double_byte_mode(dspi);
+   if (is_double_byte_mode(dspi))
+   tx_word = 2;
curr_remaining_bytes = dspi->len;
+   bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer */
-   

Re: [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format

[maitysanchayan]

Hello Stefan,

On 16-11-17 17:07:24, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index aee8c88..164e2e1 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> > }
> >  
> > val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > -   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > -   SPI_PUSHR_PCS(dspi->cs) |
> > -   SPI_PUSHR_CTAS(0);
> > +   if (dspi->cs_change) {
> > +   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > +   SPI_PUSHR_PCS(dspi->cs) |
> > +   SPI_PUSHR_CTAS(0);
> > +   } else {
> > +   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > +   SPI_PUSHR_PCS(dspi->cs) |
> > +   SPI_PUSHR_CTAS(0) |
> > +   SPI_PUSHR_CONT;
> > +   }
> 
> How about:
> 
> 
>   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
>   SPI_PUSHR_PCS(dspi->cs) |
>   SPI_PUSHR_CTAS(0);
> 
> + if (dspi->cs_change)
> + dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
> 
> 
> Avoids code duplication...

Agreed. It's much better. Should be !dspi->cs_change though.

Will include it in next iteration.

Thanks & Regards,
Sanchayan.

> 
> --
> Stefan
> 
> 
> 
> > dspi->tx += tx_word + 1;
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,

Re: [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format

[maitysanchayan]

Hello Stefan,

On 16-11-17 17:07:24, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/spi/spi-fsl-dspi.c | 13 ++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index aee8c88..164e2e1 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi 
> > *dspi)
> > }
> >  
> > val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > -   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > -   SPI_PUSHR_PCS(dspi->cs) |
> > -   SPI_PUSHR_CTAS(0);
> > +   if (dspi->cs_change) {
> > +   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > +   SPI_PUSHR_PCS(dspi->cs) |
> > +   SPI_PUSHR_CTAS(0);
> > +   } else {
> > +   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > +   SPI_PUSHR_PCS(dspi->cs) |
> > +   SPI_PUSHR_CTAS(0) |
> > +   SPI_PUSHR_CONT;
> > +   }
> 
> How about:
> 
> 
>   dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
>   SPI_PUSHR_PCS(dspi->cs) |
>   SPI_PUSHR_CTAS(0);
> 
> + if (dspi->cs_change)
> + dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
> 
> 
> Avoids code duplication...

Agreed. It's much better. Should be !dspi->cs_change though.

Will include it in next iteration.

Thanks & Regards,
Sanchayan.

> 
> --
> Stefan
> 
> 
> 
> > dspi->tx += tx_word + 1;
> >  
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,

Re: [PATCH] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3

[maitysanchayan]

On 16-11-11 20:46:12, Fabio Estevam wrote:
> On Thu, Nov 10, 2016 at 9:45 AM, Sanchayan Maity
>  wrote:
> > Enable DMA for DSPI2 and DSPI3 on Vybrid.
> 
> You missed your Signed-off-by line.

Argh...Sorry about that...Will send a follow patch with this fixed.

- Sanchayan.

Re: [PATCH] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3

[maitysanchayan]

On 16-11-11 20:46:12, Fabio Estevam wrote:
> On Thu, Nov 10, 2016 at 9:45 AM, Sanchayan Maity
>  wrote:
> > Enable DMA for DSPI2 and DSPI3 on Vybrid.
> 
> You missed your Signed-off-by line.

Argh...Sorry about that...Will send a follow patch with this fixed.

- Sanchayan.

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

[maitysanchayan]

Hello Shawn,

On 16-10-22 15:43:04, Vladimir Zapolskiy wrote:
> Hi Shawn,
> 
> On 10/22/2016 06:25 AM, Shawn Guo wrote:
> > On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote:
> > > Remove the use of DDC I2C bus bitbang to support reading of EDID
> > > and rely on support from internal HDMI I2C master controller instead.
> > > As a result remove the device tree property ddc-i2c-bus.
> > > 
> > > Signed-off-by: Sanchayan Maity 
> > 
> > I think that the dw-hdmi i2c support [1] is a prerequisite of this
> > patch.  I do not see it lands on v4.9-rc1.  Or am I missing something?
> > 
> > Shawn
> > 
> > [1] https://patchwork.kernel.org/patch/9296883/
> > 
> 
> I'm adding Philipp to Cc, since he is the last one who tested the change
> and helped me to push the change to the mainline:
> 
>   https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html
> 
> The problem is that there is no official DW HDMI bridge maintainer, may be
> you can review the change, and if you find it satisfactory push it through
> ARM/iMX tree.

Shawn, is it okay if that patch goes through your ARM/iMX tree?

- Sanchayan.

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

[maitysanchayan]

Hello Shawn,

On 16-10-22 15:43:04, Vladimir Zapolskiy wrote:
> Hi Shawn,
> 
> On 10/22/2016 06:25 AM, Shawn Guo wrote:
> > On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote:
> > > Remove the use of DDC I2C bus bitbang to support reading of EDID
> > > and rely on support from internal HDMI I2C master controller instead.
> > > As a result remove the device tree property ddc-i2c-bus.
> > > 
> > > Signed-off-by: Sanchayan Maity 
> > 
> > I think that the dw-hdmi i2c support [1] is a prerequisite of this
> > patch.  I do not see it lands on v4.9-rc1.  Or am I missing something?
> > 
> > Shawn
> > 
> > [1] https://patchwork.kernel.org/patch/9296883/
> > 
> 
> I'm adding Philipp to Cc, since he is the last one who tested the change
> and helped me to push the change to the mainline:
> 
>   https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html
> 
> The problem is that there is no official DW HDMI bridge maintainer, may be
> you can review the change, and if you find it satisfactory push it through
> ARM/iMX tree.

Shawn, is it okay if that patch goes through your ARM/iMX tree?

- Sanchayan.

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 
>  arch/arm/boot/dts/imx6qdl-colibri.dtsi   | 890 
> +++
>  3 files changed, 1144 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-aristainetos_7.dtb \
>   imx6dl-aristainetos2_4.dtb \
>   imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
>   imx6dl-cubox-i.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
>   imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> +  "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = 
> + i2c1 = 
> + };
> +
> + aliases {
> + rtc0 = _i2c;
> + rtc1 = _rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = < 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_lcdif>;
> + 

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 
>  arch/arm/boot/dts/imx6qdl-colibri.dtsi   | 890 
> +++
>  3 files changed, 1144 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-aristainetos_7.dtb \
>   imx6dl-aristainetos2_4.dtb \
>   imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
>   imx6dl-cubox-i.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
>   imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> +  "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = 
> + i2c1 = 
> + };
> +
> + aliases {
> + rtc0 = _i2c;
> + rtc1 = _rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = < 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_lcdif>;
> + status = "okay";
> +
> +  

Re: [PATCH v2] spi: spi-fsl-dspi: Add DMA support for Vybrid

[maitysanchayan]

Hello,

Ping?

Regards,
Sanchayan.

On 16-10-04 16:28:33, Sanchayan Maity wrote:
> Add DMA support for Vybrid.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v1:
> - Change in the dspi_dma_xfer function. Use more apt DSPI_FIFO_SIZE
> instead of sizeof(u32)
> - Do not set RSER on every iteration of loop
> 
> Tested on Toradex Colibri Vybrid VF61 module with spi based MCP CAN 251x
> and spidev using RX/TX loopback and based on shawn's for-next branch
> currently at 4.8-rc1.
> 
> Regards,
> Sanchayan.
> ---
>  drivers/spi/spi-fsl-dspi.c | 291 
> +
>  1 file changed, 291 insertions(+)
> 
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 9e9dadb..0f81075 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -15,6 +15,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -40,6 +42,7 @@
>  #define TRAN_STATE_WORD_ODD_NUM  0x04
>  
>  #define DSPI_FIFO_SIZE   4
> +#define DSPI_DMA_BUFSIZE (DSPI_FIFO_SIZE * 1024)
>  
>  #define SPI_MCR  0x00
>  #define SPI_MCR_MASTER   (1 << 31)
> @@ -71,6 +74,11 @@
>  #define SPI_SR_EOQF  0x1000
>  #define SPI_SR_TCFQF 0x8000
>  
> +#define SPI_RSER_TFFFE   BIT(25)
> +#define SPI_RSER_TFFFD   BIT(24)
> +#define SPI_RSER_RFDFE   BIT(17)
> +#define SPI_RSER_RFDFD   BIT(16)
> +
>  #define SPI_RSER 0x30
>  #define SPI_RSER_EOQFE   0x1000
>  #define SPI_RSER_TCFQE   0x8000
> @@ -108,6 +116,8 @@
>  
>  #define SPI_TCR_TCNT_MAX 0x1
>  
> +#define DMA_COMPLETION_TIMEOUT   msecs_to_jiffies(3000)
> +
>  struct chip_data {
>   u32 mcr_val;
>   u32 ctar_val;
> @@ -117,6 +127,7 @@ struct chip_data {
>  enum dspi_trans_mode {
>   DSPI_EOQ_MODE = 0,
>   DSPI_TCFQ_MODE,
> + DSPI_DMA_MODE,
>  };
>  
>  struct fsl_dspi_devtype_data {
> @@ -139,6 +150,22 @@ static const struct fsl_dspi_devtype_data ls2085a_data = 
> {
>   .max_clock_factor = 8,
>  };
>  
> +struct fsl_dspi_dma {
> + u32 curr_xfer_len;
> +
> + u32 *tx_dma_buf;
> + struct dma_chan *chan_tx;
> + dma_addr_t tx_dma_phys;
> + struct completion cmd_tx_complete;
> + struct dma_async_tx_descriptor *tx_desc;
> +
> + u32 *rx_dma_buf;
> + struct dma_chan *chan_rx;
> + dma_addr_t rx_dma_phys;
> + struct completion cmd_rx_complete;
> + struct dma_async_tx_descriptor *rx_desc;
> +};
> +
>  struct fsl_dspi {
>   struct spi_master   *master;
>   struct platform_device  *pdev;
> @@ -165,6 +192,7 @@ struct fsl_dspi {
>   u32 waitflags;
>  
>   u32 spi_tcnt;
> + struct fsl_dspi_dma *dma;
>  };
>  
>  static inline int is_double_byte_mode(struct fsl_dspi *dspi)
> @@ -368,6 +396,259 @@ static void dspi_tcfq_read(struct fsl_dspi *dspi)
>   dspi_data_from_popr(dspi, rx_word);
>  }
>  
> +static void dspi_tx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> +
> + complete(>cmd_tx_complete);
> +}
> +
> +static void dspi_rx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> + int rx_word;
> + int i, len;
> + u16 d;
> +
> + rx_word = is_double_byte_mode(dspi);
> +
> + len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> + for (i = 0; i < len; i++) {
> + d = dspi->dma->rx_dma_buf[i];
> + rx_word ? (*(u16 *)dspi->rx = d) :
> + (*(u8 *)dspi->rx = d);
> + dspi->rx += rx_word + 1;
> + }
> + }
> +
> + complete(>cmd_rx_complete);
> +}
> +
> +static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> +{
> + struct fsl_dspi_dma *dma = dspi->dma;
> + struct device *dev = >pdev->dev;
> + int time_left;
> + int tx_word;
> + int i, len;
> + u16 val;
> +
> + tx_word = is_double_byte_mode(dspi);
> +
> + len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + for (i = 0; i < len - 1; i++) {
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] =
> + SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
> + dspi->tx += tx_word + 1;
> + }
> +
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> + SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0);
> + dspi->tx += tx_word + 1;
> 

Re: [PATCH v2] spi: spi-fsl-dspi: Add DMA support for Vybrid

[maitysanchayan]

Hello,

Ping?

Regards,
Sanchayan.

On 16-10-04 16:28:33, Sanchayan Maity wrote:
> Add DMA support for Vybrid.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v1:
> - Change in the dspi_dma_xfer function. Use more apt DSPI_FIFO_SIZE
> instead of sizeof(u32)
> - Do not set RSER on every iteration of loop
> 
> Tested on Toradex Colibri Vybrid VF61 module with spi based MCP CAN 251x
> and spidev using RX/TX loopback and based on shawn's for-next branch
> currently at 4.8-rc1.
> 
> Regards,
> Sanchayan.
> ---
>  drivers/spi/spi-fsl-dspi.c | 291 
> +
>  1 file changed, 291 insertions(+)
> 
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 9e9dadb..0f81075 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -15,6 +15,8 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -40,6 +42,7 @@
>  #define TRAN_STATE_WORD_ODD_NUM  0x04
>  
>  #define DSPI_FIFO_SIZE   4
> +#define DSPI_DMA_BUFSIZE (DSPI_FIFO_SIZE * 1024)
>  
>  #define SPI_MCR  0x00
>  #define SPI_MCR_MASTER   (1 << 31)
> @@ -71,6 +74,11 @@
>  #define SPI_SR_EOQF  0x1000
>  #define SPI_SR_TCFQF 0x8000
>  
> +#define SPI_RSER_TFFFE   BIT(25)
> +#define SPI_RSER_TFFFD   BIT(24)
> +#define SPI_RSER_RFDFE   BIT(17)
> +#define SPI_RSER_RFDFD   BIT(16)
> +
>  #define SPI_RSER 0x30
>  #define SPI_RSER_EOQFE   0x1000
>  #define SPI_RSER_TCFQE   0x8000
> @@ -108,6 +116,8 @@
>  
>  #define SPI_TCR_TCNT_MAX 0x1
>  
> +#define DMA_COMPLETION_TIMEOUT   msecs_to_jiffies(3000)
> +
>  struct chip_data {
>   u32 mcr_val;
>   u32 ctar_val;
> @@ -117,6 +127,7 @@ struct chip_data {
>  enum dspi_trans_mode {
>   DSPI_EOQ_MODE = 0,
>   DSPI_TCFQ_MODE,
> + DSPI_DMA_MODE,
>  };
>  
>  struct fsl_dspi_devtype_data {
> @@ -139,6 +150,22 @@ static const struct fsl_dspi_devtype_data ls2085a_data = 
> {
>   .max_clock_factor = 8,
>  };
>  
> +struct fsl_dspi_dma {
> + u32 curr_xfer_len;
> +
> + u32 *tx_dma_buf;
> + struct dma_chan *chan_tx;
> + dma_addr_t tx_dma_phys;
> + struct completion cmd_tx_complete;
> + struct dma_async_tx_descriptor *tx_desc;
> +
> + u32 *rx_dma_buf;
> + struct dma_chan *chan_rx;
> + dma_addr_t rx_dma_phys;
> + struct completion cmd_rx_complete;
> + struct dma_async_tx_descriptor *rx_desc;
> +};
> +
>  struct fsl_dspi {
>   struct spi_master   *master;
>   struct platform_device  *pdev;
> @@ -165,6 +192,7 @@ struct fsl_dspi {
>   u32 waitflags;
>  
>   u32 spi_tcnt;
> + struct fsl_dspi_dma *dma;
>  };
>  
>  static inline int is_double_byte_mode(struct fsl_dspi *dspi)
> @@ -368,6 +396,259 @@ static void dspi_tcfq_read(struct fsl_dspi *dspi)
>   dspi_data_from_popr(dspi, rx_word);
>  }
>  
> +static void dspi_tx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> +
> + complete(>cmd_tx_complete);
> +}
> +
> +static void dspi_rx_dma_callback(void *arg)
> +{
> + struct fsl_dspi *dspi = arg;
> + struct fsl_dspi_dma *dma = dspi->dma;
> + int rx_word;
> + int i, len;
> + u16 d;
> +
> + rx_word = is_double_byte_mode(dspi);
> +
> + len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> + for (i = 0; i < len; i++) {
> + d = dspi->dma->rx_dma_buf[i];
> + rx_word ? (*(u16 *)dspi->rx = d) :
> + (*(u8 *)dspi->rx = d);
> + dspi->rx += rx_word + 1;
> + }
> + }
> +
> + complete(>cmd_rx_complete);
> +}
> +
> +static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> +{
> + struct fsl_dspi_dma *dma = dspi->dma;
> + struct device *dev = >pdev->dev;
> + int time_left;
> + int tx_word;
> + int i, len;
> + u16 val;
> +
> + tx_word = is_double_byte_mode(dspi);
> +
> + len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> +
> + for (i = 0; i < len - 1; i++) {
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] =
> + SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0) | SPI_PUSHR_CONT;
> + dspi->tx += tx_word + 1;
> + }
> +
> + val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> + SPI_PUSHR_PCS(dspi->cs) |
> + SPI_PUSHR_CTAS(0);
> + dspi->tx += tx_word + 1;
> +
> + dma->tx_desc = 

Re: [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid

[maitysanchayan]

Hello Stefan,

On 16-10-03 11:05:59, Stefan Agner wrote:
> On 2016-10-03 05:50, Sanchayan Maity wrote:
> > Enable DMA for DSPI on Vybrid.
> 
> Hm, we have that in 4.4 already, is that meant for 4.1?

Sorry?! I send this out for mainline and the patch series is based
on top of shawn's for-next branch. Did not intend it for our downstream
4.1.

Thanks.

Regards,
Stefan.

> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vf-colibri.dtsi | 4 
> >  arch/arm/boot/dts/vfxxx.dtsi  | 6 ++
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> > b/arch/arm/boot/dts/vf-colibri.dtsi
> > index b741709..21bfef9 100644
> > --- a/arch/arm/boot/dts/vf-colibri.dtsi
> > +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> > @@ -108,6 +108,10 @@
> > status = "okay";
> >  };
> >  
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_esdhc1>;
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 2c13ec6..eac4213 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -194,6 +194,9 @@
> > clocks = < VF610_CLK_DSPI0>;
> > clock-names = "dspi";
> > spi-num-chipselects = <6>;
> > +   dmas = < 1 12>,
> > +   < 1 13>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -206,6 +209,9 @@
> > clocks = < VF610_CLK_DSPI1>;
> > clock-names = "dspi";
> > spi-num-chipselects = <4>;
> > +   dmas = < 1 14>,
> > +   < 1 15>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };

Re: [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid

[maitysanchayan]

Hello Stefan,

On 16-10-03 11:05:59, Stefan Agner wrote:
> On 2016-10-03 05:50, Sanchayan Maity wrote:
> > Enable DMA for DSPI on Vybrid.
> 
> Hm, we have that in 4.4 already, is that meant for 4.1?

Sorry?! I send this out for mainline and the patch series is based
on top of shawn's for-next branch. Did not intend it for our downstream
4.1.

Thanks.

Regards,
Stefan.

> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vf-colibri.dtsi | 4 
> >  arch/arm/boot/dts/vfxxx.dtsi  | 6 ++
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> > b/arch/arm/boot/dts/vf-colibri.dtsi
> > index b741709..21bfef9 100644
> > --- a/arch/arm/boot/dts/vf-colibri.dtsi
> > +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> > @@ -108,6 +108,10 @@
> > status = "okay";
> >  };
> >  
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_esdhc1>;
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 2c13ec6..eac4213 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -194,6 +194,9 @@
> > clocks = < VF610_CLK_DSPI0>;
> > clock-names = "dspi";
> > spi-num-chipselects = <6>;
> > +   dmas = < 1 12>,
> > +   < 1 13>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -206,6 +209,9 @@
> > clocks = < VF610_CLK_DSPI1>;
> > clock-names = "dspi";
> > spi-num-chipselects = <4>;
> > +   dmas = < 1 14>,
> > +   < 1 15>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 16-09-19 10:41:51, Sanchayan Maity wrote:
> Remove the use of DDC I2C bus bitbang to support reading of EDID
> and rely on support from internal HDMI I2C master controller instead.
> As a result remove the device tree property ddc-i2c-bus.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v1:
> 
> Change the ranking in i2c aliases
> 
> v1: https://lkml.org/lkml/2016/9/14/55
> ---
>  arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++-
>  arch/arm/boot/dts/imx6qdl-apalis.dtsi| 25 +
>  2 files changed, 12 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts 
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index 207b85b..82b81e0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -55,10 +55,9 @@
>"fsl,imx6q";
>  
>   aliases {
> - i2c0 = 
> - i2c1 = 
> - i2c2 = 
> - i2c3 = 
> + i2c0 = 
> + i2c1 = 
> + i2c2 = 
>   };
>  
>   aliases {
> @@ -186,11 +185,6 @@
>  };
>  
>   {
> - ddc-i2c-bus = <>;
> - status = "okay";
> -};
> -
> - {
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi 
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 99e323b..8c67dd8 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -53,18 +53,6 @@
>   status = "disabled";
>   };
>  
> - /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> - i2cddc: i2c@0 {
> - compatible = "i2c-gpio";
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c_ddc>;
> - gpios = < 16 GPIO_ACTIVE_HIGH /* sda */
> -   30 GPIO_ACTIVE_HIGH /* scl */
> - >;
> - i2c-gpio,delay-us = <2>;/* ~100 kHz */
> - status = "disabled";
> - };
> -
>   reg_1p8v: regulator-1p8v {
>   compatible = "regulator-fixed";
>   regulator-name = "1P8V";
> @@ -209,6 +197,12 @@
>   };
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_hdmi_ddc>;
> + status = "disabled";
> +};
> +
>  /*
>   * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
>   * board)
> @@ -633,11 +627,10 @@
>   >;
>   };
>  
> - pinctrl_i2c_ddc: gpioi2cddcgrp {
> + pinctrl_hdmi_ddc: hdmiddcgrp {
>   fsl,pins = <
> - /* DDC bitbang */
> - MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> - MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> + MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
>   >;
>   };
>  
> -- 
> 2.9.3
> 

Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 16-09-19 10:41:51, Sanchayan Maity wrote:
> Remove the use of DDC I2C bus bitbang to support reading of EDID
> and rely on support from internal HDMI I2C master controller instead.
> As a result remove the device tree property ddc-i2c-bus.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v1:
> 
> Change the ranking in i2c aliases
> 
> v1: https://lkml.org/lkml/2016/9/14/55
> ---
>  arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++-
>  arch/arm/boot/dts/imx6qdl-apalis.dtsi| 25 +
>  2 files changed, 12 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts 
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index 207b85b..82b81e0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -55,10 +55,9 @@
>"fsl,imx6q";
>  
>   aliases {
> - i2c0 = 
> - i2c1 = 
> - i2c2 = 
> - i2c3 = 
> + i2c0 = 
> + i2c1 = 
> + i2c2 = 
>   };
>  
>   aliases {
> @@ -186,11 +185,6 @@
>  };
>  
>   {
> - ddc-i2c-bus = <>;
> - status = "okay";
> -};
> -
> - {
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi 
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 99e323b..8c67dd8 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -53,18 +53,6 @@
>   status = "disabled";
>   };
>  
> - /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> - i2cddc: i2c@0 {
> - compatible = "i2c-gpio";
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c_ddc>;
> - gpios = < 16 GPIO_ACTIVE_HIGH /* sda */
> -   30 GPIO_ACTIVE_HIGH /* scl */
> - >;
> - i2c-gpio,delay-us = <2>;/* ~100 kHz */
> - status = "disabled";
> - };
> -
>   reg_1p8v: regulator-1p8v {
>   compatible = "regulator-fixed";
>   regulator-name = "1P8V";
> @@ -209,6 +197,12 @@
>   };
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_hdmi_ddc>;
> + status = "disabled";
> +};
> +
>  /*
>   * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
>   * board)
> @@ -633,11 +627,10 @@
>   >;
>   };
>  
> - pinctrl_i2c_ddc: gpioi2cddcgrp {
> + pinctrl_hdmi_ddc: hdmiddcgrp {
>   fsl,pins = <
> - /* DDC bitbang */
> - MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> - MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> + MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
>   >;
>   };
>  
> -- 
> 2.9.3
> 

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 
>  arch/arm/boot/dts/imx6qdl-colibri.dtsi   | 890 
> +++
>  3 files changed, 1144 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-aristainetos_7.dtb \
>   imx6dl-aristainetos2_4.dtb \
>   imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
>   imx6dl-cubox-i.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
>   imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> +  "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = 
> + i2c1 = 
> + };
> +
> + aliases {
> + rtc0 = _i2c;
> + rtc1 = _rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = < 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_lcdif>;
> + 

Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 
>  arch/arm/boot/dts/imx6qdl-colibri.dtsi   | 890 
> +++
>  3 files changed, 1144 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-aristainetos_7.dtb \
>   imx6dl-aristainetos2_4.dtb \
>   imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
>   imx6dl-cubox-i.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
>   imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> +  "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = 
> + i2c1 = 
> + };
> +
> + aliases {
> + rtc0 = _i2c;
> + rtc1 = _rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = < 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_lcdif>;
> + status = "okay";
> +
> +  

Re: [PATCH v1 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight

[maitysanchayan]

Hello Marcel,

On 16-09-16 13:38:54, Marcel Ziswiler wrote:
> On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> > Use enable-gpios property of PWM backlight driver for backlight
> > control. While at it also fix the use of brightness levels required
> > by EDT displays which require inverted PWM's.
> 
> That part I am missing below. Did you forget to include it?

No, actually I missed fixing the commit message. Currently PWM polarity
inversion is not supported and while checking, I kept the brightness
levels as is currently but did not change the commit message.

Will send a v2 and fix this.

Regards,
Sanchayan.

> 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 8c67dd8..9100bde 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -49,7 +49,10 @@
> >  
> >     backlight: backlight {
> >     compatible = "pwm-backlight";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_gpio_bl_on>;
> >     pwms = < 0 500>;
> > +   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
> >     status = "disabled";
> >     };
> >  
> > @@ -614,6 +617,12 @@
> >     >;
> >     };
> >  
> > +   pinctrl_gpio_bl_on: gpioblon {
> > +   fsl,pins = <
> > +   MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
> > +   >;
> > +   };
> > +
> >     pinctrl_gpio_keys: gpio1io04grp {
> >     fsl,pins = <
> >     /* Power button */

Re: [PATCH v1 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight

[maitysanchayan]

Hello Marcel,

On 16-09-16 13:38:54, Marcel Ziswiler wrote:
> On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> > Use enable-gpios property of PWM backlight driver for backlight
> > control. While at it also fix the use of brightness levels required
> > by EDT displays which require inverted PWM's.
> 
> That part I am missing below. Did you forget to include it?

No, actually I missed fixing the commit message. Currently PWM polarity
inversion is not supported and while checking, I kept the brightness
levels as is currently but did not change the commit message.

Will send a v2 and fix this.

Regards,
Sanchayan.

> 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 8c67dd8..9100bde 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -49,7 +49,10 @@
> >  
> >     backlight: backlight {
> >     compatible = "pwm-backlight";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_gpio_bl_on>;
> >     pwms = < 0 500>;
> > +   enable-gpios = < 13 GPIO_ACTIVE_HIGH>;
> >     status = "disabled";
> >     };
> >  
> > @@ -614,6 +617,12 @@
> >     >;
> >     };
> >  
> > +   pinctrl_gpio_bl_on: gpioblon {
> > +   fsl,pins = <
> > +   MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
> > +   >;
> > +   };
> > +
> >     pinctrl_gpio_keys: gpio1io04grp {
> >     fsl,pins = <
> >     /* Power button */

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[maitysanchayan]

On 16-07-08 18:23:42, Srinivas Kandagatla wrote:
> 
> 
> On 08/07/16 17:42, Stefan Agner wrote:
> > On 2016-07-08 08:41, Srinivas Kandagatla wrote:
> > > On 07/07/16 14:48, maitysancha...@gmail.com wrote:
> > > > Hello Srinivas,
> > > > 
> > > > On 16-07-07 1
> 
> ...
> 
> > > > > > 
> > > > > > Our requirement is to be able to pass the soc node pointer and then
> > > > > > be able to get a nvmem cell by specifying it's name. So for our case
> > > > > 
> > > > > Why?
> > > > 
> > > > Sorry for not providing the background directly. The patches before this
> > > > series used that approach. In the previous discussions it has been 
> > > > pointed
> > > > out that it is not acceptable to have additional device tree bindings 
> > > > for
> > > > providing data that the driver wants at the SoC node level or to have 
> > > > bindings
> > > > just for the SoC bus driver alone since we aren't really describing the
> > > > hardware.
> > > > 
> > > SOC driver seems to search for an arbitrary node by its name, which is
> > > not a binding and can break anytime in cases If the scope of nvmem
> > > provider is out of soc node or if the nvmem cells are not named as
> > > expected. That looks very fragile.
> > 
> > In that case, that just "won't happen" because the soc driver is a very
> > soc specific driver only used for this device tree. We it will always
> > bind to that high level soc node.
> > 
> > > 
> > > If the soc node is actual consumer of nvmem cells, I see no reason why
> > > we should not use proper nvmem bindings?
> > 
> > There is a reason: We don't describe the hardware with it...
> > 
> > The cfg0/cfg1 register which Sanchayan needs to read in the soc bus
> > driver are just two register with a unique ID of the SoC. In whatever
> 
> "Unique ID of the SOC" doesn't this mean that its a part of soc hw
> description/configuration/setup?
> 
> Am still not clear why this setup any different to other use cases like mac
> address/calibration data?
> 
> I still feel that this should be described in the DT.
> 
> Rob,
>  What do you think?

Hello Rob,

Can you please comment?

Regards,
Sanchayan.

> 
> 
> > driver throughout the system we use that ID (e.g. in a random generator
> > for initialization) we never describe an actual hardware relation... Its
> > just software and how we use that unique ID. The device tree is ment to
> > describe hardware. Hence the NVMEM consumer binding is not suited for
> > such NVMEM cells...
> > 
> > By describing the NVMEM cells location in device tree (producer API, the
> > NVMEM cells are in hardware at that location, so using the device tree
> > for that part is fine) and hard coding the NVMEM cell we need in the
> > driver code we don't violate the device tree matra "describe the
> > hardware"...
> 
> IMHO, We should indeed describe the SOC hardware and its relationship w.r.t
> to nvmem provider in device tree. Reasoning being these both are some form
> of IP blocks/hw which depend on each other.
> 
> > 
> > Looking-up the nodes direcly is what Rob suggested here:
> > https://lkml.org/lkml/2016/5/23/573
> 
> I did read this, I was not convinced that we should do a direct lookup for
> nvmem cells.
> 
> thanks,
> srini
> > 
> > > 
> > > Given the fact that the patch is potentially bypassing the nvmem
> > > bindings, am not happy to take it!
> > 
> > If you can provide a solution acceptable by the device tree folks and
> > works without this patch, I am happy to do it...
> 
> 
> > 
> > Btw, I am not entirely happy with the API name, but did not had a better
> > idea... And we we should probably add a note that the device tree
> > consumer binding is the preferred way to do it.
> > 
> > --
> > Stefan
> > 
> > 
> > > 
> > > thanks,
> > > srini
> > > 
> > > > For the discussion,
> > > > https://lkml.org/lkml/2016/5/23/573
> > > > https://lkml.org/lkml/2016/5/2/71
> > > > 
> > > > Regards,
> > > > Sanchayan.
> > > > 
> > > > 
> > > > > 
> > > > > > ocotp node has cfg0 and cfg1 which we want but we cannot use 
> > > > > > existing
> > > > > > nvmem consumer API since that requires having the nvmem consumer 
> > > > > > properties
> > > > > > in the node we are binding to viz. is a direct nvmem consumer.
> > > > > > 
> > > > > > Regards,
> > > > > > Sanchayan.
> > > > > > 
> > > > > > > 
> > > > > > > thanks,
> > > > > > > srini
> > > > > > > > 
> > > > > > > > Parent node can also be the of_node of the main SoC device
> > > > > > > > node.
> > > > > > > > 
> > > > > > > > Signed-off-by: Sanchayan Maity 
> > > > > > > > ---
> > > > > > > >  drivers/nvmem/core.c   | 44 
> > > > > > > > +-
> > > > > > > >  include/linux/nvmem-consumer.h |  1 +
> > > > > > > >  2 files changed, 32 insertions(+), 13 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > > > > > > > index 965911d..470abee 100644
> > > > > > > > --- a/drivers/nvmem/core.c
> > > > > > > > 

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[maitysanchayan]

On 16-07-08 18:23:42, Srinivas Kandagatla wrote:
> 
> 
> On 08/07/16 17:42, Stefan Agner wrote:
> > On 2016-07-08 08:41, Srinivas Kandagatla wrote:
> > > On 07/07/16 14:48, maitysancha...@gmail.com wrote:
> > > > Hello Srinivas,
> > > > 
> > > > On 16-07-07 1
> 
> ...
> 
> > > > > > 
> > > > > > Our requirement is to be able to pass the soc node pointer and then
> > > > > > be able to get a nvmem cell by specifying it's name. So for our case
> > > > > 
> > > > > Why?
> > > > 
> > > > Sorry for not providing the background directly. The patches before this
> > > > series used that approach. In the previous discussions it has been 
> > > > pointed
> > > > out that it is not acceptable to have additional device tree bindings 
> > > > for
> > > > providing data that the driver wants at the SoC node level or to have 
> > > > bindings
> > > > just for the SoC bus driver alone since we aren't really describing the
> > > > hardware.
> > > > 
> > > SOC driver seems to search for an arbitrary node by its name, which is
> > > not a binding and can break anytime in cases If the scope of nvmem
> > > provider is out of soc node or if the nvmem cells are not named as
> > > expected. That looks very fragile.
> > 
> > In that case, that just "won't happen" because the soc driver is a very
> > soc specific driver only used for this device tree. We it will always
> > bind to that high level soc node.
> > 
> > > 
> > > If the soc node is actual consumer of nvmem cells, I see no reason why
> > > we should not use proper nvmem bindings?
> > 
> > There is a reason: We don't describe the hardware with it...
> > 
> > The cfg0/cfg1 register which Sanchayan needs to read in the soc bus
> > driver are just two register with a unique ID of the SoC. In whatever
> 
> "Unique ID of the SOC" doesn't this mean that its a part of soc hw
> description/configuration/setup?
> 
> Am still not clear why this setup any different to other use cases like mac
> address/calibration data?
> 
> I still feel that this should be described in the DT.
> 
> Rob,
>  What do you think?

Hello Rob,

Can you please comment?

Regards,
Sanchayan.

> 
> 
> > driver throughout the system we use that ID (e.g. in a random generator
> > for initialization) we never describe an actual hardware relation... Its
> > just software and how we use that unique ID. The device tree is ment to
> > describe hardware. Hence the NVMEM consumer binding is not suited for
> > such NVMEM cells...
> > 
> > By describing the NVMEM cells location in device tree (producer API, the
> > NVMEM cells are in hardware at that location, so using the device tree
> > for that part is fine) and hard coding the NVMEM cell we need in the
> > driver code we don't violate the device tree matra "describe the
> > hardware"...
> 
> IMHO, We should indeed describe the SOC hardware and its relationship w.r.t
> to nvmem provider in device tree. Reasoning being these both are some form
> of IP blocks/hw which depend on each other.
> 
> > 
> > Looking-up the nodes direcly is what Rob suggested here:
> > https://lkml.org/lkml/2016/5/23/573
> 
> I did read this, I was not convinced that we should do a direct lookup for
> nvmem cells.
> 
> thanks,
> srini
> > 
> > > 
> > > Given the fact that the patch is potentially bypassing the nvmem
> > > bindings, am not happy to take it!
> > 
> > If you can provide a solution acceptable by the device tree folks and
> > works without this patch, I am happy to do it...
> 
> 
> > 
> > Btw, I am not entirely happy with the API name, but did not had a better
> > idea... And we we should probably add a note that the device tree
> > consumer binding is the preferred way to do it.
> > 
> > --
> > Stefan
> > 
> > 
> > > 
> > > thanks,
> > > srini
> > > 
> > > > For the discussion,
> > > > https://lkml.org/lkml/2016/5/23/573
> > > > https://lkml.org/lkml/2016/5/2/71
> > > > 
> > > > Regards,
> > > > Sanchayan.
> > > > 
> > > > 
> > > > > 
> > > > > > ocotp node has cfg0 and cfg1 which we want but we cannot use 
> > > > > > existing
> > > > > > nvmem consumer API since that requires having the nvmem consumer 
> > > > > > properties
> > > > > > in the node we are binding to viz. is a direct nvmem consumer.
> > > > > > 
> > > > > > Regards,
> > > > > > Sanchayan.
> > > > > > 
> > > > > > > 
> > > > > > > thanks,
> > > > > > > srini
> > > > > > > > 
> > > > > > > > Parent node can also be the of_node of the main SoC device
> > > > > > > > node.
> > > > > > > > 
> > > > > > > > Signed-off-by: Sanchayan Maity 
> > > > > > > > ---
> > > > > > > >  drivers/nvmem/core.c   | 44 
> > > > > > > > +-
> > > > > > > >  include/linux/nvmem-consumer.h |  1 +
> > > > > > > >  2 files changed, 32 insertions(+), 13 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > > > > > > > index 965911d..470abee 100644
> > > > > > > > --- a/drivers/nvmem/core.c
> > > > > > > > +++ 

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[maitysanchayan]

Hello Srinivas,

On 16-07-07 14:16:36, Srinivas Kandagatla wrote:
> 
> 
> On 07/07/16 13:33, maitysancha...@gmail.com wrote:
> > Hello Srinivas,
> > 
> > On 16-07-07 10:18:49, Srinivas Kandagatla wrote:
> > > 
> > > 
> > > On 07/07/16 07:39, Sanchayan Maity wrote:
> > > > From: Stefan Agner 
> > > > 
> > > > The existing NVMEM consumer API's do not allow to get a
> > > > NVMEM cell directly given a device tree node. This patch
> > > > adds a function to provide this functionality.
> > > > 
> > > > Assuming the nvmem cell id name is known, this can be used
> > > > as follows
> > > > 
> > > > struct device_node *cell_np;
> > > > struct nvmem_cell *foo_cell;
> > > > 
> > > > cell_np = of_find_node_by_name(parent, "foo");
> > > > foo_cell = of_nvmem_cell_get_direct(cell_np);
> > > 
> > > I don't see a real gain in adding this new api,
> > > This will encourage people to use non-standard nvmem bindings.
> > > 
> > > why not just use standard nvmem bindings.. and use
> > > 
> > > of_nvmem_cell_get(np, "foo");
> > > 
> > > which should work in your case.
> > 
> > It will not work in our case. I believe what you are referring to will
> > work if I were to pass the device node pointer which was a NVMEM consumer
> > containing the nvmem-cells property. In our case, we pass the device node
> > pointer pointing to /soc which is not a nvmem consumer. In this case it
> > will not have nvmem-cells property causing of_nvmem_cell_get to return
> > EINVAL when it calls of_parse_phandle with "nvmem-cells".
> 
> I could not see any bindings/ dt patches or dt examples for this this
> series.. so Am guessing your node would look like:
> 
> soc {
>   cfg0: cfg0 {
>   ...
>   };
>   cfg1: cfg1 {
>   ...
>   };
> };
> 
> If this is not how it looks, can you share the details.
> 
> What Am saying is that why not have:
> 
> soc {
>   nvmem-cells = <>, <>;
>   nvmem-cell-names = "cfg0", "cfg1";
> 
>   cfg0: cfg0 {
>   ...
>   };
> 
>   cfg1: cfg1 {
>   ...
>   };
> };
> 
> > 
> > Our requirement is to be able to pass the soc node pointer and then
> > be able to get a nvmem cell by specifying it's name. So for our case
> 
> Why?

Sorry for not providing the background directly. The patches before this
series used that approach. In the previous discussions it has been pointed
out that it is not acceptable to have additional device tree bindings for
providing data that the driver wants at the SoC node level or to have bindings
just for the SoC bus driver alone since we aren't really describing the
hardware.

For the discussion,
https://lkml.org/lkml/2016/5/23/573
https://lkml.org/lkml/2016/5/2/71

Regards,
Sanchayan.


> 
> > ocotp node has cfg0 and cfg1 which we want but we cannot use existing
> > nvmem consumer API since that requires having the nvmem consumer properties
> > in the node we are binding to viz. is a direct nvmem consumer.
> > 
> > Regards,
> > Sanchayan.
> > 
> > > 
> > > thanks,
> > > srini
> > > > 
> > > > Parent node can also be the of_node of the main SoC device
> > > > node.
> > > > 
> > > > Signed-off-by: Sanchayan Maity 
> > > > ---
> > > >drivers/nvmem/core.c   | 44 
> > > > +-
> > > >include/linux/nvmem-consumer.h |  1 +
> > > >2 files changed, 32 insertions(+), 13 deletions(-)
> > > > 
> > > > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > > > index 965911d..470abee 100644
> > > > --- a/drivers/nvmem/core.c
> > > > +++ b/drivers/nvmem/core.c
> > > > @@ -743,29 +743,21 @@ static struct nvmem_cell 
> > > > *nvmem_cell_get_from_list(const char *cell_id)
> > > > 
> > > >#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
> > > >/**
> > > > - * of_nvmem_cell_get() - Get a nvmem cell from given device node and 
> > > > cell id
> > > > + * of_nvmem_cell_get_direct() - Get a nvmem cell from given device node
> > > > *
> > > > - * @dev node: Device tree node that uses the nvmem cell
> > > > - * @id: nvmem cell name from nvmem-cell-names property.
> > > > + * @dev node: Device tree node that uses nvmem cell
> > > > *
> > > > * Return: Will be an ERR_PTR() on error or a valid pointer
> > > > * to a struct nvmem_cell.  The nvmem_cell will be freed by the
> > > > * nvmem_cell_put().
> > > > */
> > > > -struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > > > -   const char *name)
> > > > +struct nvmem_cell *of_nvmem_cell_get_direct(struct device_node 
> > > > *cell_np)
> > > >{
> > > > -   struct device_node *cell_np, *nvmem_np;
> > > > +   struct device_node *nvmem_np;
> > > > struct nvmem_cell *cell;
> > > > struct nvmem_device *nvmem;
> > > > const __be32 *addr;
> > > > -   int rval, len, index;
> > > > -
> > > > -   index = of_property_match_string(np, "nvmem-cell-names", name);
> > > > -

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[maitysanchayan]

Hello Srinivas,

On 16-07-07 14:16:36, Srinivas Kandagatla wrote:
> 
> 
> On 07/07/16 13:33, maitysancha...@gmail.com wrote:
> > Hello Srinivas,
> > 
> > On 16-07-07 10:18:49, Srinivas Kandagatla wrote:
> > > 
> > > 
> > > On 07/07/16 07:39, Sanchayan Maity wrote:
> > > > From: Stefan Agner 
> > > > 
> > > > The existing NVMEM consumer API's do not allow to get a
> > > > NVMEM cell directly given a device tree node. This patch
> > > > adds a function to provide this functionality.
> > > > 
> > > > Assuming the nvmem cell id name is known, this can be used
> > > > as follows
> > > > 
> > > > struct device_node *cell_np;
> > > > struct nvmem_cell *foo_cell;
> > > > 
> > > > cell_np = of_find_node_by_name(parent, "foo");
> > > > foo_cell = of_nvmem_cell_get_direct(cell_np);
> > > 
> > > I don't see a real gain in adding this new api,
> > > This will encourage people to use non-standard nvmem bindings.
> > > 
> > > why not just use standard nvmem bindings.. and use
> > > 
> > > of_nvmem_cell_get(np, "foo");
> > > 
> > > which should work in your case.
> > 
> > It will not work in our case. I believe what you are referring to will
> > work if I were to pass the device node pointer which was a NVMEM consumer
> > containing the nvmem-cells property. In our case, we pass the device node
> > pointer pointing to /soc which is not a nvmem consumer. In this case it
> > will not have nvmem-cells property causing of_nvmem_cell_get to return
> > EINVAL when it calls of_parse_phandle with "nvmem-cells".
> 
> I could not see any bindings/ dt patches or dt examples for this this
> series.. so Am guessing your node would look like:
> 
> soc {
>   cfg0: cfg0 {
>   ...
>   };
>   cfg1: cfg1 {
>   ...
>   };
> };
> 
> If this is not how it looks, can you share the details.
> 
> What Am saying is that why not have:
> 
> soc {
>   nvmem-cells = <>, <>;
>   nvmem-cell-names = "cfg0", "cfg1";
> 
>   cfg0: cfg0 {
>   ...
>   };
> 
>   cfg1: cfg1 {
>   ...
>   };
> };
> 
> > 
> > Our requirement is to be able to pass the soc node pointer and then
> > be able to get a nvmem cell by specifying it's name. So for our case
> 
> Why?

Sorry for not providing the background directly. The patches before this
series used that approach. In the previous discussions it has been pointed
out that it is not acceptable to have additional device tree bindings for
providing data that the driver wants at the SoC node level or to have bindings
just for the SoC bus driver alone since we aren't really describing the
hardware.

For the discussion,
https://lkml.org/lkml/2016/5/23/573
https://lkml.org/lkml/2016/5/2/71

Regards,
Sanchayan.


> 
> > ocotp node has cfg0 and cfg1 which we want but we cannot use existing
> > nvmem consumer API since that requires having the nvmem consumer properties
> > in the node we are binding to viz. is a direct nvmem consumer.
> > 
> > Regards,
> > Sanchayan.
> > 
> > > 
> > > thanks,
> > > srini
> > > > 
> > > > Parent node can also be the of_node of the main SoC device
> > > > node.
> > > > 
> > > > Signed-off-by: Sanchayan Maity 
> > > > ---
> > > >drivers/nvmem/core.c   | 44 
> > > > +-
> > > >include/linux/nvmem-consumer.h |  1 +
> > > >2 files changed, 32 insertions(+), 13 deletions(-)
> > > > 
> > > > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > > > index 965911d..470abee 100644
> > > > --- a/drivers/nvmem/core.c
> > > > +++ b/drivers/nvmem/core.c
> > > > @@ -743,29 +743,21 @@ static struct nvmem_cell 
> > > > *nvmem_cell_get_from_list(const char *cell_id)
> > > > 
> > > >#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
> > > >/**
> > > > - * of_nvmem_cell_get() - Get a nvmem cell from given device node and 
> > > > cell id
> > > > + * of_nvmem_cell_get_direct() - Get a nvmem cell from given device node
> > > > *
> > > > - * @dev node: Device tree node that uses the nvmem cell
> > > > - * @id: nvmem cell name from nvmem-cell-names property.
> > > > + * @dev node: Device tree node that uses nvmem cell
> > > > *
> > > > * Return: Will be an ERR_PTR() on error or a valid pointer
> > > > * to a struct nvmem_cell.  The nvmem_cell will be freed by the
> > > > * nvmem_cell_put().
> > > > */
> > > > -struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > > > -   const char *name)
> > > > +struct nvmem_cell *of_nvmem_cell_get_direct(struct device_node 
> > > > *cell_np)
> > > >{
> > > > -   struct device_node *cell_np, *nvmem_np;
> > > > +   struct device_node *nvmem_np;
> > > > struct nvmem_cell *cell;
> > > > struct nvmem_device *nvmem;
> > > > const __be32 *addr;
> > > > -   int rval, len, index;
> > > > -
> > > > -   index = of_property_match_string(np, "nvmem-cell-names", name);
> > > > -
> > > > -   cell_np = 

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[maitysanchayan]

Hello Srinivas,

On 16-07-07 10:18:49, Srinivas Kandagatla wrote:
> 
> 
> On 07/07/16 07:39, Sanchayan Maity wrote:
> > From: Stefan Agner 
> > 
> > The existing NVMEM consumer API's do not allow to get a
> > NVMEM cell directly given a device tree node. This patch
> > adds a function to provide this functionality.
> > 
> > Assuming the nvmem cell id name is known, this can be used
> > as follows
> > 
> > struct device_node *cell_np;
> > struct nvmem_cell *foo_cell;
> > 
> > cell_np = of_find_node_by_name(parent, "foo");
> > foo_cell = of_nvmem_cell_get_direct(cell_np);
> 
> I don't see a real gain in adding this new api,
> This will encourage people to use non-standard nvmem bindings.
> 
> why not just use standard nvmem bindings.. and use
> 
> of_nvmem_cell_get(np, "foo");
> 
> which should work in your case.

It will not work in our case. I believe what you are referring to will
work if I were to pass the device node pointer which was a NVMEM consumer
containing the nvmem-cells property. In our case, we pass the device node
pointer pointing to /soc which is not a nvmem consumer. In this case it
will not have nvmem-cells property causing of_nvmem_cell_get to return
EINVAL when it calls of_parse_phandle with "nvmem-cells".

Our requirement is to be able to pass the soc node pointer and then
be able to get a nvmem cell by specifying it's name. So for our case
ocotp node has cfg0 and cfg1 which we want but we cannot use existing
nvmem consumer API since that requires having the nvmem consumer properties
in the node we are binding to viz. is a direct nvmem consumer.

Regards,
Sanchayan.

> 
> thanks,
> srini
> > 
> > Parent node can also be the of_node of the main SoC device
> > node.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >   drivers/nvmem/core.c   | 44 
> > +-
> >   include/linux/nvmem-consumer.h |  1 +
> >   2 files changed, 32 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > index 965911d..470abee 100644
> > --- a/drivers/nvmem/core.c
> > +++ b/drivers/nvmem/core.c
> > @@ -743,29 +743,21 @@ static struct nvmem_cell 
> > *nvmem_cell_get_from_list(const char *cell_id)
> > 
> >   #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
> >   /**
> > - * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell 
> > id
> > + * of_nvmem_cell_get_direct() - Get a nvmem cell from given device node
> >*
> > - * @dev node: Device tree node that uses the nvmem cell
> > - * @id: nvmem cell name from nvmem-cell-names property.
> > + * @dev node: Device tree node that uses nvmem cell
> >*
> >* Return: Will be an ERR_PTR() on error or a valid pointer
> >* to a struct nvmem_cell.  The nvmem_cell will be freed by the
> >* nvmem_cell_put().
> >*/
> > -struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > -   const char *name)
> > +struct nvmem_cell *of_nvmem_cell_get_direct(struct device_node *cell_np)
> >   {
> > -   struct device_node *cell_np, *nvmem_np;
> > +   struct device_node *nvmem_np;
> > struct nvmem_cell *cell;
> > struct nvmem_device *nvmem;
> > const __be32 *addr;
> > -   int rval, len, index;
> > -
> > -   index = of_property_match_string(np, "nvmem-cell-names", name);
> > -
> > -   cell_np = of_parse_phandle(np, "nvmem-cells", index);
> > -   if (!cell_np)
> > -   return ERR_PTR(-EINVAL);
> > +   int rval, len;
> > 
> > nvmem_np = of_get_next_parent(cell_np);
> > if (!nvmem_np)
> > @@ -824,6 +816,32 @@ err_mem:
> > 
> > return ERR_PTR(rval);
> >   }
> > +EXPORT_SYMBOL_GPL(of_nvmem_cell_get_direct);
> > +
> > +/**
> > + * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell 
> > id
> > + *
> > + * @dev node: Device tree node that uses the nvmem cell
> > + * @id: nvmem cell name from nvmem-cell-names property.
> > + *
> > + * Return: Will be an ERR_PTR() on error or a valid pointer
> > + * to a struct nvmem_cell.  The nvmem_cell will be freed by the
> > + * nvmem_cell_put().
> > + */
> > +struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > +   const char *name)
> > +{
> > +   struct device_node *cell_np;
> > +   int index;
> > +
> > +   index = of_property_match_string(np, "nvmem-cell-names", name);
> > +
> > +   cell_np = of_parse_phandle(np, "nvmem-cells", index);
> > +   if (!cell_np)
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   return of_nvmem_cell_get_direct(cell_np);
> > +}
> >   EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
> >   #endif
> > 
> > diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
> > index 9bb77d3..bf879fc 100644
> > --- a/include/linux/nvmem-consumer.h
> > +++ b/include/linux/nvmem-consumer.h
> > @@ -136,6 +136,7 @@ static inline int nvmem_device_write(struct 
> > nvmem_device *nvmem,
> >   #endif /* CONFIG_NVMEM */
> > 
> >   

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[maitysanchayan]

Hello Srinivas,

On 16-07-07 10:18:49, Srinivas Kandagatla wrote:
> 
> 
> On 07/07/16 07:39, Sanchayan Maity wrote:
> > From: Stefan Agner 
> > 
> > The existing NVMEM consumer API's do not allow to get a
> > NVMEM cell directly given a device tree node. This patch
> > adds a function to provide this functionality.
> > 
> > Assuming the nvmem cell id name is known, this can be used
> > as follows
> > 
> > struct device_node *cell_np;
> > struct nvmem_cell *foo_cell;
> > 
> > cell_np = of_find_node_by_name(parent, "foo");
> > foo_cell = of_nvmem_cell_get_direct(cell_np);
> 
> I don't see a real gain in adding this new api,
> This will encourage people to use non-standard nvmem bindings.
> 
> why not just use standard nvmem bindings.. and use
> 
> of_nvmem_cell_get(np, "foo");
> 
> which should work in your case.

It will not work in our case. I believe what you are referring to will
work if I were to pass the device node pointer which was a NVMEM consumer
containing the nvmem-cells property. In our case, we pass the device node
pointer pointing to /soc which is not a nvmem consumer. In this case it
will not have nvmem-cells property causing of_nvmem_cell_get to return
EINVAL when it calls of_parse_phandle with "nvmem-cells".

Our requirement is to be able to pass the soc node pointer and then
be able to get a nvmem cell by specifying it's name. So for our case
ocotp node has cfg0 and cfg1 which we want but we cannot use existing
nvmem consumer API since that requires having the nvmem consumer properties
in the node we are binding to viz. is a direct nvmem consumer.

Regards,
Sanchayan.

> 
> thanks,
> srini
> > 
> > Parent node can also be the of_node of the main SoC device
> > node.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >   drivers/nvmem/core.c   | 44 
> > +-
> >   include/linux/nvmem-consumer.h |  1 +
> >   2 files changed, 32 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > index 965911d..470abee 100644
> > --- a/drivers/nvmem/core.c
> > +++ b/drivers/nvmem/core.c
> > @@ -743,29 +743,21 @@ static struct nvmem_cell 
> > *nvmem_cell_get_from_list(const char *cell_id)
> > 
> >   #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
> >   /**
> > - * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell 
> > id
> > + * of_nvmem_cell_get_direct() - Get a nvmem cell from given device node
> >*
> > - * @dev node: Device tree node that uses the nvmem cell
> > - * @id: nvmem cell name from nvmem-cell-names property.
> > + * @dev node: Device tree node that uses nvmem cell
> >*
> >* Return: Will be an ERR_PTR() on error or a valid pointer
> >* to a struct nvmem_cell.  The nvmem_cell will be freed by the
> >* nvmem_cell_put().
> >*/
> > -struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > -   const char *name)
> > +struct nvmem_cell *of_nvmem_cell_get_direct(struct device_node *cell_np)
> >   {
> > -   struct device_node *cell_np, *nvmem_np;
> > +   struct device_node *nvmem_np;
> > struct nvmem_cell *cell;
> > struct nvmem_device *nvmem;
> > const __be32 *addr;
> > -   int rval, len, index;
> > -
> > -   index = of_property_match_string(np, "nvmem-cell-names", name);
> > -
> > -   cell_np = of_parse_phandle(np, "nvmem-cells", index);
> > -   if (!cell_np)
> > -   return ERR_PTR(-EINVAL);
> > +   int rval, len;
> > 
> > nvmem_np = of_get_next_parent(cell_np);
> > if (!nvmem_np)
> > @@ -824,6 +816,32 @@ err_mem:
> > 
> > return ERR_PTR(rval);
> >   }
> > +EXPORT_SYMBOL_GPL(of_nvmem_cell_get_direct);
> > +
> > +/**
> > + * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell 
> > id
> > + *
> > + * @dev node: Device tree node that uses the nvmem cell
> > + * @id: nvmem cell name from nvmem-cell-names property.
> > + *
> > + * Return: Will be an ERR_PTR() on error or a valid pointer
> > + * to a struct nvmem_cell.  The nvmem_cell will be freed by the
> > + * nvmem_cell_put().
> > + */
> > +struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
> > +   const char *name)
> > +{
> > +   struct device_node *cell_np;
> > +   int index;
> > +
> > +   index = of_property_match_string(np, "nvmem-cell-names", name);
> > +
> > +   cell_np = of_parse_phandle(np, "nvmem-cells", index);
> > +   if (!cell_np)
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   return of_nvmem_cell_get_direct(cell_np);
> > +}
> >   EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
> >   #endif
> > 
> > diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
> > index 9bb77d3..bf879fc 100644
> > --- a/include/linux/nvmem-consumer.h
> > +++ b/include/linux/nvmem-consumer.h
> > @@ -136,6 +136,7 @@ static inline int nvmem_device_write(struct 
> > nvmem_device *nvmem,
> >   #endif /* CONFIG_NVMEM */
> > 
> >   #if IS_ENABLED(CONFIG_NVMEM) && 

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-27 15:38:17, maitysancha...@gmail.com wrote:
> On 16-05-27 10:31:55, Arnd Bergmann wrote:
> > On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> > > 
> > > So if I understand correctly, the binding at the SoC level is fine.
> > > Keeping that but removing the additional made-up properties, viz. below
> > > 
> > > rom-revision: phandle to the on-chip ROM node
> > > mscm: phandle to the MSCM CPU configuration node
> > > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > > 
> > > would be fine?
> > > 
> > > We would have something similar to here
> > > http://www.spinics.net/lists/devicetree/msg80655.html
> > > 
> > > but now with the DT binding under SoC bus.
> > > 
> > 
> > 
> > You look up the OTP device as a syscon here, which seems odd since there
> > is already an nvmem driver for it. Shouldn't you use the nvmem API for
> > that?
> > 
> > Arnd
> 
> I need the following 
> 
> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> to be able to use the NVMEM consumer API.
> 
> If I can put them at SoC node level then I certainly can use the NVMEM API.
> 

Would the following be acceptable at the SoC node level

> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"

Regards,
Sanchayan.
 

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-27 15:38:17, maitysancha...@gmail.com wrote:
> On 16-05-27 10:31:55, Arnd Bergmann wrote:
> > On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> > > 
> > > So if I understand correctly, the binding at the SoC level is fine.
> > > Keeping that but removing the additional made-up properties, viz. below
> > > 
> > > rom-revision: phandle to the on-chip ROM node
> > > mscm: phandle to the MSCM CPU configuration node
> > > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > > 
> > > would be fine?
> > > 
> > > We would have something similar to here
> > > http://www.spinics.net/lists/devicetree/msg80655.html
> > > 
> > > but now with the DT binding under SoC bus.
> > > 
> > 
> > 
> > You look up the OTP device as a syscon here, which seems odd since there
> > is already an nvmem driver for it. Shouldn't you use the nvmem API for
> > that?
> > 
> > Arnd
> 
> I need the following 
> 
> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> to be able to use the NVMEM consumer API.
> 
> If I can put them at SoC node level then I certainly can use the NVMEM API.
> 

Would the following be acceptable at the SoC node level

> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"

Regards,
Sanchayan.
 

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Stefan,

On 16-05-27 10:28:45, Stefan Agner wrote:
> On 2016-05-27 03:08, maitysancha...@gmail.com wrote:
> > On 16-05-27 10:31:55, Arnd Bergmann wrote:
> >> On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> >> >
> >> > So if I understand correctly, the binding at the SoC level is fine.
> >> > Keeping that but removing the additional made-up properties, viz. below
> >> >
> >> > rom-revision: phandle to the on-chip ROM node
> >> > mscm: phandle to the MSCM CPU configuration node
> >> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> >> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> >> >
> >> > would be fine?
> >> >
> >> > We would have something similar to here
> >> > http://www.spinics.net/lists/devicetree/msg80655.html
> >> >
> >> > but now with the DT binding under SoC bus.
> >> >
> >>
> >>
> >> You look up the OTP device as a syscon here, which seems odd since there
> >> is already an nvmem driver for it. Shouldn't you use the nvmem API for
> >> that?
> >>
> >>Arnd
> > 
> > I need the following 
> > 
> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > 
> > to be able to use the NVMEM consumer API.
> 
> I did not tested it, but it seems the NVMEM consumer API has some kind
> of non-DT fallback:
> http://lxr.free-electrons.com/source/drivers/nvmem/core.c#L827
> 
> Right now, it seems to me that it does not handle the case where we have
> a of_node but don't want to use it... You might need to add some extra
> handling if there is a of_node without nvmem-cell-names/nvmem-cells, and
> fall back to nvmem_cell_get_from_list.
> 

I have already looked at the core nvmem code for options but wanted to avoid
any additons if possible.

However if adding the nvmem properties at the SoC node level is frowned upon
I will make the necessary changes required.

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Stefan,

On 16-05-27 10:28:45, Stefan Agner wrote:
> On 2016-05-27 03:08, maitysancha...@gmail.com wrote:
> > On 16-05-27 10:31:55, Arnd Bergmann wrote:
> >> On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> >> >
> >> > So if I understand correctly, the binding at the SoC level is fine.
> >> > Keeping that but removing the additional made-up properties, viz. below
> >> >
> >> > rom-revision: phandle to the on-chip ROM node
> >> > mscm: phandle to the MSCM CPU configuration node
> >> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> >> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> >> >
> >> > would be fine?
> >> >
> >> > We would have something similar to here
> >> > http://www.spinics.net/lists/devicetree/msg80655.html
> >> >
> >> > but now with the DT binding under SoC bus.
> >> >
> >>
> >>
> >> You look up the OTP device as a syscon here, which seems odd since there
> >> is already an nvmem driver for it. Shouldn't you use the nvmem API for
> >> that?
> >>
> >>Arnd
> > 
> > I need the following 
> > 
> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > 
> > to be able to use the NVMEM consumer API.
> 
> I did not tested it, but it seems the NVMEM consumer API has some kind
> of non-DT fallback:
> http://lxr.free-electrons.com/source/drivers/nvmem/core.c#L827
> 
> Right now, it seems to me that it does not handle the case where we have
> a of_node but don't want to use it... You might need to add some extra
> handling if there is a of_node without nvmem-cell-names/nvmem-cells, and
> fall back to nvmem_cell_get_from_list.
> 

I have already looked at the core nvmem code for options but wanted to avoid
any additons if possible.

However if adding the nvmem properties at the SoC node level is frowned upon
I will make the necessary changes required.

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

On 16-05-27 10:31:55, Arnd Bergmann wrote:
> On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> > 
> > So if I understand correctly, the binding at the SoC level is fine.
> > Keeping that but removing the additional made-up properties, viz. below
> > 
> > rom-revision: phandle to the on-chip ROM node
> > mscm: phandle to the MSCM CPU configuration node
> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > 
> > would be fine?
> > 
> > We would have something similar to here
> > http://www.spinics.net/lists/devicetree/msg80655.html
> > 
> > but now with the DT binding under SoC bus.
> > 
> 
> 
> You look up the OTP device as a syscon here, which seems odd since there
> is already an nvmem driver for it. Shouldn't you use the nvmem API for
> that?
> 
>   Arnd

I need the following 

nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
nvmem-cell-names: should contain string names "cfg0" and "cfg1"

to be able to use the NVMEM consumer API.

If I can put them at SoC node level then I certainly can use the NVMEM API.

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

On 16-05-27 10:31:55, Arnd Bergmann wrote:
> On Friday, May 27, 2016 12:03:01 PM CEST maitysancha...@gmail.com wrote:
> > 
> > So if I understand correctly, the binding at the SoC level is fine.
> > Keeping that but removing the additional made-up properties, viz. below
> > 
> > rom-revision: phandle to the on-chip ROM node
> > mscm: phandle to the MSCM CPU configuration node
> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> > 
> > would be fine?
> > 
> > We would have something similar to here
> > http://www.spinics.net/lists/devicetree/msg80655.html
> > 
> > but now with the DT binding under SoC bus.
> > 
> 
> 
> You look up the OTP device as a syscon here, which seems odd since there
> is already an nvmem driver for it. Shouldn't you use the nvmem API for
> that?
> 
>   Arnd

I need the following 

nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
nvmem-cell-names: should contain string names "cfg0" and "cfg1"

to be able to use the NVMEM consumer API.

If I can put them at SoC node level then I certainly can use the NVMEM API.

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-24 12:09:41, Rob Herring wrote:
> On Mon, May 23, 2016 at 11:14 PM,   wrote:
> > Hello Rob,
> >
> > On 16-05-23 16:18:13, Rob Herring wrote:
> >> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> >> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> >> > Driver utilises syscon and nvmem consumer API's to get the
> >> > various register values needed and expose the SoC specific
> >> > properties via sysfs.
> >> >
> >> > A sample output from Colibri Vybrid VF61 is below:
> >> >
> >> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> >> > family machinepower  revision   soc_id subsystem  uevent
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> >> > Freescale Vybrid VF610
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> >> > Freescale Vybrid
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> >> > 0013
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> >> > df6472a6130f29d4
> >> >
> >> > Signed-off-by: Sanchayan Maity 
> >> > ---
> >> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >> >  drivers/soc/Kconfig|   1 +
> >> >  drivers/soc/fsl/Kconfig|  10 ++
> >> >  drivers/soc/fsl/Makefile   |   1 +
> >> >  drivers/soc/fsl/soc-vf610.c| 198 
> >> > +
> >> >  5 files changed, 230 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> >  create mode 100644 drivers/soc/fsl/Kconfig
> >> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> >> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> > new file mode 100644
> >> > index 000..338905d
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> > @@ -0,0 +1,20 @@
> >> > +Vybrid System-on-Chip
> >> > +-
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: "fsl,vf610-soc"
> >> > +- rom-revision: phandle to the on-chip ROM node
> >> > +- mscm: phandle to the MSCM CPU configuration node
> >> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and 
> >> > ocotp_cfg1
> >> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> >>
> >> I still have similar concerns as the discussion on the last version.
> >> This version only proves that you aren't describing h/w, but rather just
> >> a collection of data that some driver wants.
> >>
> >> A driver can just as easily look-up all the nodes directly that these
> >> phandles point to.
> >
> > Agreed, that we can look up all the nodes directly that these phandles
> > refer to but I would still need a DT entry to bind to. While I could
> > bind to existing nodes like mscm cpucfg but that doesn't seem right.
> >
> > The very first approach that we had taken was to integrate this 
> > functionality
> > in mach-vf610.c code under mach-imx
> > http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Yes, everyone wants to move all platform devices in the kernel to a
> corresponding DT node. The result is often making up nodes to do this.
> It's the same thing with cpufreq.
> 
> > and then it was recommended to migrate this to drivers/soc where we did use
> > phandles or direct look up via compatible strings
> 
> The location in the tree is an orthogonal issue. You could move it and
> use of_machine_is_compatible without any DT change.
> 
> The primary issue I have here is how do we bind soc_bus to DT in a
> consistent way. Sorry, but vybrid specific patches alone are never
> going to solve that issue.
> 
> > http://www.spinics.net/lists/arm-kernel/msg420847.html
> >
> > and
> >
> > http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> >
> > There hasn't been a consensus since v1.
> 
> I actually prefer your previous version binding soc_bus to the root
> bus node to this version. I think that is closer to the right
> direction. 

So if I understand correctly, the binding at the SoC level is fine.
Keeping that but removing the additional made-up properties, viz. below

rom-revision: phandle to the on-chip ROM node
mscm: phandle to the MSCM CPU configuration node
nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
nvmem-cell-names: should contain string names "cfg0" and "cfg1"

would be fine?

We would have something similar to here
http://www.spinics.net/lists/devicetree/msg80655.html

but now with the DT binding under SoC bus.

Regards,
Sanchayan.

> After all, pretty much everything is an SOC and every SOC
> has an SOC bus. Pretty much every SOC and board have revisions and may
> need to expose that revision info as well. We have to do 

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-24 12:09:41, Rob Herring wrote:
> On Mon, May 23, 2016 at 11:14 PM,   wrote:
> > Hello Rob,
> >
> > On 16-05-23 16:18:13, Rob Herring wrote:
> >> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> >> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> >> > Driver utilises syscon and nvmem consumer API's to get the
> >> > various register values needed and expose the SoC specific
> >> > properties via sysfs.
> >> >
> >> > A sample output from Colibri Vybrid VF61 is below:
> >> >
> >> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> >> > family machinepower  revision   soc_id subsystem  uevent
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> >> > Freescale Vybrid VF610
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> >> > Freescale Vybrid
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> >> > 0013
> >> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> >> > df6472a6130f29d4
> >> >
> >> > Signed-off-by: Sanchayan Maity 
> >> > ---
> >> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >> >  drivers/soc/Kconfig|   1 +
> >> >  drivers/soc/fsl/Kconfig|  10 ++
> >> >  drivers/soc/fsl/Makefile   |   1 +
> >> >  drivers/soc/fsl/soc-vf610.c| 198 
> >> > +
> >> >  5 files changed, 230 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> >  create mode 100644 drivers/soc/fsl/Kconfig
> >> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> >> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> > new file mode 100644
> >> > index 000..338905d
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >> > @@ -0,0 +1,20 @@
> >> > +Vybrid System-on-Chip
> >> > +-
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: "fsl,vf610-soc"
> >> > +- rom-revision: phandle to the on-chip ROM node
> >> > +- mscm: phandle to the MSCM CPU configuration node
> >> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and 
> >> > ocotp_cfg1
> >> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> >>
> >> I still have similar concerns as the discussion on the last version.
> >> This version only proves that you aren't describing h/w, but rather just
> >> a collection of data that some driver wants.
> >>
> >> A driver can just as easily look-up all the nodes directly that these
> >> phandles point to.
> >
> > Agreed, that we can look up all the nodes directly that these phandles
> > refer to but I would still need a DT entry to bind to. While I could
> > bind to existing nodes like mscm cpucfg but that doesn't seem right.
> >
> > The very first approach that we had taken was to integrate this 
> > functionality
> > in mach-vf610.c code under mach-imx
> > http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Yes, everyone wants to move all platform devices in the kernel to a
> corresponding DT node. The result is often making up nodes to do this.
> It's the same thing with cpufreq.
> 
> > and then it was recommended to migrate this to drivers/soc where we did use
> > phandles or direct look up via compatible strings
> 
> The location in the tree is an orthogonal issue. You could move it and
> use of_machine_is_compatible without any DT change.
> 
> The primary issue I have here is how do we bind soc_bus to DT in a
> consistent way. Sorry, but vybrid specific patches alone are never
> going to solve that issue.
> 
> > http://www.spinics.net/lists/arm-kernel/msg420847.html
> >
> > and
> >
> > http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> >
> > There hasn't been a consensus since v1.
> 
> I actually prefer your previous version binding soc_bus to the root
> bus node to this version. I think that is closer to the right
> direction. 

So if I understand correctly, the binding at the SoC level is fine.
Keeping that but removing the additional made-up properties, viz. below

rom-revision: phandle to the on-chip ROM node
mscm: phandle to the MSCM CPU configuration node
nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
nvmem-cell-names: should contain string names "cfg0" and "cfg1"

would be fine?

We would have something similar to here
http://www.spinics.net/lists/devicetree/msg80655.html

but now with the DT binding under SoC bus.

Regards,
Sanchayan.

> After all, pretty much everything is an SOC and every SOC
> has an SOC bus. Pretty much every SOC and board have revisions and may
> need to expose that revision info as well. We have to do this
> consistently which means having a default 

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-23 16:18:13, Rob Herring wrote:
> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> > Driver utilises syscon and nvmem consumer API's to get the
> > various register values needed and expose the SoC specific
> > properties via sysfs.
> > 
> > A sample output from Colibri Vybrid VF61 is below:
> > 
> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> > family machinepower  revision   soc_id subsystem  uevent
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> > Freescale Vybrid VF610
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> > Freescale Vybrid
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> > 0013
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> > df6472a6130f29d4
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >  drivers/soc/Kconfig|   1 +
> >  drivers/soc/fsl/Kconfig|  10 ++
> >  drivers/soc/fsl/Makefile   |   1 +
> >  drivers/soc/fsl/soc-vf610.c| 198 
> > +
> >  5 files changed, 230 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >  create mode 100644 drivers/soc/fsl/Kconfig
> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..338905d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,20 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- compatible: "fsl,vf610-soc"
> > +- rom-revision: phandle to the on-chip ROM node
> > +- mscm: phandle to the MSCM CPU configuration node
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> I still have similar concerns as the discussion on the last version. 
> This version only proves that you aren't describing h/w, but rather just 
> a collection of data that some driver wants.
> 
> A driver can just as easily look-up all the nodes directly that these 
> phandles point to.

Agreed, that we can look up all the nodes directly that these phandles
refer to but I would still need a DT entry to bind to. While I could
bind to existing nodes like mscm cpucfg but that doesn't seem right.

The very first approach that we had taken was to integrate this functionality
in mach-vf610.c code under mach-imx
http://www.spinics.net/lists/devicetree/msg80654.html

and then it was recommended to migrate this to drivers/soc where we did use
phandles or direct look up via compatible strings

http://www.spinics.net/lists/arm-kernel/msg420847.html

and

http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html

There hasn't been a consensus since v1.

> 
> And as long as we have inconsistent use of soc_device, I don't want to 
> see any compatible strings related to it.
> 

Regards,
Sanchayan.

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-23 16:18:13, Rob Herring wrote:
> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> > Driver utilises syscon and nvmem consumer API's to get the
> > various register values needed and expose the SoC specific
> > properties via sysfs.
> > 
> > A sample output from Colibri Vybrid VF61 is below:
> > 
> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> > family machinepower  revision   soc_id subsystem  uevent
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> > Freescale Vybrid VF610
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> > Freescale Vybrid
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> > 0013
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> > df6472a6130f29d4
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >  drivers/soc/Kconfig|   1 +
> >  drivers/soc/fsl/Kconfig|  10 ++
> >  drivers/soc/fsl/Makefile   |   1 +
> >  drivers/soc/fsl/soc-vf610.c| 198 
> > +
> >  5 files changed, 230 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >  create mode 100644 drivers/soc/fsl/Kconfig
> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..338905d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,20 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- compatible: "fsl,vf610-soc"
> > +- rom-revision: phandle to the on-chip ROM node
> > +- mscm: phandle to the MSCM CPU configuration node
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> I still have similar concerns as the discussion on the last version. 
> This version only proves that you aren't describing h/w, but rather just 
> a collection of data that some driver wants.
> 
> A driver can just as easily look-up all the nodes directly that these 
> phandles point to.

Agreed, that we can look up all the nodes directly that these phandles
refer to but I would still need a DT entry to bind to. While I could
bind to existing nodes like mscm cpucfg but that doesn't seem right.

The very first approach that we had taken was to integrate this functionality
in mach-vf610.c code under mach-imx
http://www.spinics.net/lists/devicetree/msg80654.html

and then it was recommended to migrate this to drivers/soc where we did use
phandles or direct look up via compatible strings

http://www.spinics.net/lists/arm-kernel/msg420847.html

and

http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html

There hasn't been a consensus since v1.

> 
> And as long as we have inconsistent use of soc_device, I don't want to 
> see any compatible strings related to it.
> 

Regards,
Sanchayan.

Re: [PATCH v2 5/5] vf610-soc: Add Vybrid SoC device tree binding documentation

[maitysanchayan]

Hello Rob,

On 16-05-03 21:30:26, Rob Herring wrote:
> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
> > Add device tree binding documentation for Vybrid SoC.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   | 35 
> > ++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..bdd95e8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,35 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- #address-cells: must be 1
> > +- #size-cells: must be 1
> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
> 
> If this is a bus, put the file in bindings/bus/...

The fsl,vf610-soc-bus binding is used to bind the driver in question with
an appropriate compatible node.

Basically being a standalone platform driver, there was need of a compatible
property to bind on. Introducing a separate device tree node for it's sake
didn't seem appropriate so the alteration to SoC node's compatible.

> 
> > +- interrupt-parent: phandle to the MSCM interrupt router node
> > +- ranges
> > +- fsl,rom-revision: phandle to the on-chip ROM node and address of rom
> > +  revision register
> 
> Why is this needed here? Can't you search the tree for the ROM node and 
> get this info.

Strictly per say this and next two can be specified in their respective nodes
of ocrom and mscm cpucfg, however they would then require the use of syscon_
regmap_lookup_by_compatible and this seems clean along with the introduction
of new syscon_regmap_read_from_offset function used with SoC node.

> 
> > +- fsl,cpu-count: phandle to the MSCM CPU configuration node and address of
> > +  CPU count register
> > +- fsl,l2-size: phandle to the MSCM CPU configuration node and address of
> > +  L2 cache size register
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> How are all these properties used?

All the above five are used to get the relevant values from the registers and
expose the information for SoC sysfs device.
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc

nvmem are consumer nodes which are accessed using the NVMEM consumer API's
leveraging the NVMEM framework and NVMEM vf610 ocotp driver.

Regards,
Sanchayan.

> 
> > +
> > +Example:
> > +
> > +   soc {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "fsl,vf610-soc-bus", "simple-bus";
> > +   interrupt-parent = <_ir>;
> > +   ranges;
> > +   fsl,rom-revision = < 0x80>;
> > +   fsl,cpu-count = <_cpucfg 0x2C>;
> > +   fsl,l2-size = <_cpucfg 0x14>;
> > +   nvmem-cells = <_cfg0>, <_cfg1>;
> > +   nvmem-cell-names = "cfg0", "cfg1";
> > +
> > +   ...
> > +   };
> > -- 
> > 2.8.2
> > 

Re: [PATCH v2 5/5] vf610-soc: Add Vybrid SoC device tree binding documentation

[maitysanchayan]

Hello Rob,

On 16-05-03 21:30:26, Rob Herring wrote:
> On Mon, May 02, 2016 at 12:35:04PM +0530, Sanchayan Maity wrote:
> > Add device tree binding documentation for Vybrid SoC.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   | 35 
> > ++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..bdd95e8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,35 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- #address-cells: must be 1
> > +- #size-cells: must be 1
> > +- compatible: "fsl,vf610-soc-bus", "simple-bus"
> 
> If this is a bus, put the file in bindings/bus/...

The fsl,vf610-soc-bus binding is used to bind the driver in question with
an appropriate compatible node.

Basically being a standalone platform driver, there was need of a compatible
property to bind on. Introducing a separate device tree node for it's sake
didn't seem appropriate so the alteration to SoC node's compatible.

> 
> > +- interrupt-parent: phandle to the MSCM interrupt router node
> > +- ranges
> > +- fsl,rom-revision: phandle to the on-chip ROM node and address of rom
> > +  revision register
> 
> Why is this needed here? Can't you search the tree for the ROM node and 
> get this info.

Strictly per say this and next two can be specified in their respective nodes
of ocrom and mscm cpucfg, however they would then require the use of syscon_
regmap_lookup_by_compatible and this seems clean along with the introduction
of new syscon_regmap_read_from_offset function used with SoC node.

> 
> > +- fsl,cpu-count: phandle to the MSCM CPU configuration node and address of
> > +  CPU count register
> > +- fsl,l2-size: phandle to the MSCM CPU configuration node and address of
> > +  L2 cache size register
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> How are all these properties used?

All the above five are used to get the relevant values from the registers and
expose the information for SoC sysfs device.
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc

nvmem are consumer nodes which are accessed using the NVMEM consumer API's
leveraging the NVMEM framework and NVMEM vf610 ocotp driver.

Regards,
Sanchayan.

> 
> > +
> > +Example:
> > +
> > +   soc {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   compatible = "fsl,vf610-soc-bus", "simple-bus";
> > +   interrupt-parent = <_ir>;
> > +   ranges;
> > +   fsl,rom-revision = < 0x80>;
> > +   fsl,cpu-count = <_cpucfg 0x2C>;
> > +   fsl,l2-size = <_cpucfg 0x14>;
> > +   nvmem-cells = <_cfg0>, <_cfg1>;
> > +   nvmem-cell-names = "cfg0", "cfg1";
> > +
> > +   ...
> > +   };
> > -- 
> > 2.8.2
> > 

Re: [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP

[maitysanchayan]

Hello Arnd,

On 16-05-02 09:31:12, Arnd Bergmann wrote:
> On Monday 02 May 2016 12:35:01 Sanchayan Maity wrote:
> > +   ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xCF0>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +
> > +   ocotp_cfg0: cfg0@410 {
> > +   reg = <0x410 0x4>;
> > +   };
> > +
> > +   ocotp_cfg1: cfg1@420 {
> > +   reg = <0x420 0x4>;
> > +   };
> > +   };
> 
> How do the registers of the child nodes relate to the registers of the
> parent? If there are in the same address space, it might be good to
> add a "ranges" property to describe it.

cfg0 and cfg1 are in the same address space viz. 0x400a5410 and 0x400a5420
respectively. These nodes are primarily for use by the NVMEM consumer API in
the SoC bus driver to retrieve the values from these registers leveraging
the NVMEM vf610 ocotp driver.

Based on the NVMEM bindings here
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/nvmem/nvmem.txt#L33

Thanks.

Regards,
Sanchayan.

> 
>   Arnd

> Date: Mon, 02 May 2016 12:02:21 +1000
> From: Gavin Shan 
> To: Rob Herring 
> Cc: "devicet...@vger.kernel.org" ,
>  a...@ozlabs.ru, Gavin Shan , Grant Likely
>  , "linux-...@vger.kernel.org"
>  , Bjorn Helgaas ,
>  linuxppc-dev , d...@axtens.net
> Subject: Re: [PATCH v8 40/45] drivers/of: Split unflatten_dt_node()
> 
> On Wed, Feb 17, 2016 at 08:30:42AM -0600, Rob Herring wrote:
> >On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan  
> >wrote:
> >> The function unflatten_dt_node() is called recursively to unflatten
> >> device nodes and properties in the FDT blob. It looks complicated
> >> and hard to be understood.
> >>
> >> This splits the function into 3 functions: populate_properties(),
> >> populate_node() and unflatten_dt_node(). populate_properties(),
> >> which is called by populate_node(), creates properties for the
> >> indicated device node. The later one creates the device nodes
> >> from FDT blob. populate_node() gets the offset in FDT blob for
> >> next device nodes and then calls populate_node(). No logical
> >> changes introduced.
> >>
> >> Signed-off-by: Gavin Shan 
> >> ---
> >>  drivers/of/fdt.c | 249 
> >> ---
> >>  1 file changed, 147 insertions(+), 102 deletions(-)
> >
> >One nit, otherwise:
> >
> >Acked-by: Rob Herring 
> >
> >[...]
> >
> >> +   /* And we process the "ibm,phandle" property
> >> +* used in pSeries dynamic device tree
> >> +* stuff
> >> +*/
> >> +   if (!strcmp(pname, "ibm,phandle"))
> >> +   np->phandle = be32_to_cpup(val);
> >> +
> >> +   pp->name   = (char *)pname;
> >> +   pp->length = sz;
> >> +   pp->value  = (__be32 *)val;
> >
> >This cast should not be needed.
> >
> 
> It's needed. Otherwise, we will have warning. So I will keep it. I just
> went through this one for next revision and sorry for late response.
> 
> drivers/of/fdt.c:225:14: warning: assignment discards ‘const’ qualifier from 
> pointer target type
>pp->value  = val;
>   ^
> 
> Thanks,
> Gavin
> 
> >> +   *pprev = pp;
> >> +   pprev  = >next;
> >> +   }
> >
> 
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/5] ARM: dts: vfxxx: Add device tree node for OCOTP

[maitysanchayan]

Hello Arnd,

On 16-05-02 09:31:12, Arnd Bergmann wrote:
> On Monday 02 May 2016 12:35:01 Sanchayan Maity wrote:
> > +   ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xCF0>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +
> > +   ocotp_cfg0: cfg0@410 {
> > +   reg = <0x410 0x4>;
> > +   };
> > +
> > +   ocotp_cfg1: cfg1@420 {
> > +   reg = <0x420 0x4>;
> > +   };
> > +   };
> 
> How do the registers of the child nodes relate to the registers of the
> parent? If there are in the same address space, it might be good to
> add a "ranges" property to describe it.

cfg0 and cfg1 are in the same address space viz. 0x400a5410 and 0x400a5420
respectively. These nodes are primarily for use by the NVMEM consumer API in
the SoC bus driver to retrieve the values from these registers leveraging
the NVMEM vf610 ocotp driver.

Based on the NVMEM bindings here
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/nvmem/nvmem.txt#L33

Thanks.

Regards,
Sanchayan.

> 
>   Arnd

> Date: Mon, 02 May 2016 12:02:21 +1000
> From: Gavin Shan 
> To: Rob Herring 
> Cc: "devicet...@vger.kernel.org" ,
>  a...@ozlabs.ru, Gavin Shan , Grant Likely
>  , "linux-...@vger.kernel.org"
>  , Bjorn Helgaas ,
>  linuxppc-dev , d...@axtens.net
> Subject: Re: [PATCH v8 40/45] drivers/of: Split unflatten_dt_node()
> 
> On Wed, Feb 17, 2016 at 08:30:42AM -0600, Rob Herring wrote:
> >On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan  
> >wrote:
> >> The function unflatten_dt_node() is called recursively to unflatten
> >> device nodes and properties in the FDT blob. It looks complicated
> >> and hard to be understood.
> >>
> >> This splits the function into 3 functions: populate_properties(),
> >> populate_node() and unflatten_dt_node(). populate_properties(),
> >> which is called by populate_node(), creates properties for the
> >> indicated device node. The later one creates the device nodes
> >> from FDT blob. populate_node() gets the offset in FDT blob for
> >> next device nodes and then calls populate_node(). No logical
> >> changes introduced.
> >>
> >> Signed-off-by: Gavin Shan 
> >> ---
> >>  drivers/of/fdt.c | 249 
> >> ---
> >>  1 file changed, 147 insertions(+), 102 deletions(-)
> >
> >One nit, otherwise:
> >
> >Acked-by: Rob Herring 
> >
> >[...]
> >
> >> +   /* And we process the "ibm,phandle" property
> >> +* used in pSeries dynamic device tree
> >> +* stuff
> >> +*/
> >> +   if (!strcmp(pname, "ibm,phandle"))
> >> +   np->phandle = be32_to_cpup(val);
> >> +
> >> +   pp->name   = (char *)pname;
> >> +   pp->length = sz;
> >> +   pp->value  = (__be32 *)val;
> >
> >This cast should not be needed.
> >
> 
> It's needed. Otherwise, we will have warning. So I will keep it. I just
> went through this one for next revision and sorry for late response.
> 
> drivers/of/fdt.c:225:14: warning: assignment discards ‘const’ qualifier from 
> pointer target type
>pp->value  = val;
>   ^
> 
> Thanks,
> Gavin
> 
> >> +   *pprev = pp;
> >> +   pprev  = >next;
> >> +   }
> >
> 
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 05/12] nvmem: vif610-ocotp: remove nvmem regmap dependency

[maitysanchayan]

Hello Srinivas,

On 16-04-24 20:28:09, Srinivas Kandagatla wrote:
> This patch moves to nvmem support in the driver to use callback
> instead of regmap.

Minor nit, it says "vif610-octop" it should have been vf610-ocotp.

For what it's worth, I tested this on Colibri Vybrid VF61 for a while and
all seems to work fine.

So with the testing for vf610-ocotp driver other than the minor nit

Acked-by: Sanchayan Maity 

Regards,
Sanchayan.

> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/nvmem/vf610-ocotp.c | 44 ++--
>  1 file changed, 10 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> index 8641319..72e4faa 100644
> --- a/drivers/nvmem/vf610-ocotp.c
> +++ b/drivers/nvmem/vf610-ocotp.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  /* OCOTP Register Offsets */
> @@ -152,23 +151,16 @@ static int vf610_get_fuse_address(int base_addr_offset)
>   return -EINVAL;
>  }
>  
> -static int vf610_ocotp_write(void *context, const void *data, size_t count)
> -{
> - return 0;
> -}
> -
> -static int vf610_ocotp_read(void *context,
> - const void *off, size_t reg_size,
> - void *val, size_t val_size)
> +static int vf610_ocotp_read(void *context, unsigned int offset,
> + void *val, size_t bytes)
>  {
>   struct vf610_ocotp *ocotp = context;
>   void __iomem *base = ocotp->base;
> - unsigned int offset = *(u32 *)off;
>   u32 reg, *buf = val;
>   int fuse_addr;
>   int ret;
>  
> - while (val_size > 0) {
> + while (bytes > 0) {
>   fuse_addr = vf610_get_fuse_address(offset);
>   if (fuse_addr > 0) {
>   writel(ocotp->timing, base + OCOTP_TIMING);
> @@ -205,29 +197,19 @@ static int vf610_ocotp_read(void *context,
>   }
>  
>   buf++;
> - val_size--;
> - offset += reg_size;
> + bytes -= 4;
> + offset += 4;
>   }
>  
>   return 0;
>  }
>  
> -static struct regmap_bus vf610_ocotp_bus = {
> - .read = vf610_ocotp_read,
> - .write = vf610_ocotp_write,
> - .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
> - .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
> -};
> -
> -static struct regmap_config ocotp_regmap_config = {
> - .reg_bits = 32,
> - .val_bits = 32,
> - .reg_stride = 4,
> -};
> -
>  static struct nvmem_config ocotp_config = {
>   .name = "ocotp",
>   .owner = THIS_MODULE,
> + .stride = 4,
> + .word_size = 4,
> + .reg_read = vf610_ocotp_read,
>  };
>  
>  static const struct of_device_id ocotp_of_match[] = {
> @@ -247,7 +229,6 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   struct resource *res;
> - struct regmap *regmap;
>   struct vf610_ocotp *ocotp_dev;
>  
>   ocotp_dev = devm_kzalloc(>dev,
> @@ -267,13 +248,8 @@ static int vf610_ocotp_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(ocotp_dev->clk);
>   }
>  
> - ocotp_regmap_config.max_register = resource_size(res);
> - regmap = devm_regmap_init(dev,
> - _ocotp_bus, ocotp_dev, _regmap_config);
> - if (IS_ERR(regmap)) {
> - dev_err(dev, "regmap init failed\n");
> - return PTR_ERR(regmap);
> - }
> + ocotp_config.size = resource_size(res);
> + ocotp_config.priv = ocotp_dev;
>   ocotp_config.dev = dev;
>  
>   ocotp_dev->nvmem = nvmem_register(_config);
> -- 
> 2.5.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 05/12] nvmem: vif610-ocotp: remove nvmem regmap dependency

[maitysanchayan]

Hello Srinivas,

On 16-04-24 20:28:09, Srinivas Kandagatla wrote:
> This patch moves to nvmem support in the driver to use callback
> instead of regmap.

Minor nit, it says "vif610-octop" it should have been vf610-ocotp.

For what it's worth, I tested this on Colibri Vybrid VF61 for a while and
all seems to work fine.

So with the testing for vf610-ocotp driver other than the minor nit

Acked-by: Sanchayan Maity 

Regards,
Sanchayan.

> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  drivers/nvmem/vf610-ocotp.c | 44 ++--
>  1 file changed, 10 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> index 8641319..72e4faa 100644
> --- a/drivers/nvmem/vf610-ocotp.c
> +++ b/drivers/nvmem/vf610-ocotp.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  /* OCOTP Register Offsets */
> @@ -152,23 +151,16 @@ static int vf610_get_fuse_address(int base_addr_offset)
>   return -EINVAL;
>  }
>  
> -static int vf610_ocotp_write(void *context, const void *data, size_t count)
> -{
> - return 0;
> -}
> -
> -static int vf610_ocotp_read(void *context,
> - const void *off, size_t reg_size,
> - void *val, size_t val_size)
> +static int vf610_ocotp_read(void *context, unsigned int offset,
> + void *val, size_t bytes)
>  {
>   struct vf610_ocotp *ocotp = context;
>   void __iomem *base = ocotp->base;
> - unsigned int offset = *(u32 *)off;
>   u32 reg, *buf = val;
>   int fuse_addr;
>   int ret;
>  
> - while (val_size > 0) {
> + while (bytes > 0) {
>   fuse_addr = vf610_get_fuse_address(offset);
>   if (fuse_addr > 0) {
>   writel(ocotp->timing, base + OCOTP_TIMING);
> @@ -205,29 +197,19 @@ static int vf610_ocotp_read(void *context,
>   }
>  
>   buf++;
> - val_size--;
> - offset += reg_size;
> + bytes -= 4;
> + offset += 4;
>   }
>  
>   return 0;
>  }
>  
> -static struct regmap_bus vf610_ocotp_bus = {
> - .read = vf610_ocotp_read,
> - .write = vf610_ocotp_write,
> - .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
> - .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
> -};
> -
> -static struct regmap_config ocotp_regmap_config = {
> - .reg_bits = 32,
> - .val_bits = 32,
> - .reg_stride = 4,
> -};
> -
>  static struct nvmem_config ocotp_config = {
>   .name = "ocotp",
>   .owner = THIS_MODULE,
> + .stride = 4,
> + .word_size = 4,
> + .reg_read = vf610_ocotp_read,
>  };
>  
>  static const struct of_device_id ocotp_of_match[] = {
> @@ -247,7 +229,6 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   struct resource *res;
> - struct regmap *regmap;
>   struct vf610_ocotp *ocotp_dev;
>  
>   ocotp_dev = devm_kzalloc(>dev,
> @@ -267,13 +248,8 @@ static int vf610_ocotp_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(ocotp_dev->clk);
>   }
>  
> - ocotp_regmap_config.max_register = resource_size(res);
> - regmap = devm_regmap_init(dev,
> - _ocotp_bus, ocotp_dev, _regmap_config);
> - if (IS_ERR(regmap)) {
> - dev_err(dev, "regmap init failed\n");
> - return PTR_ERR(regmap);
> - }
> + ocotp_config.size = resource_size(res);
> + ocotp_config.priv = ocotp_dev;
>   ocotp_config.dev = dev;
>  
>   ocotp_dev->nvmem = nvmem_register(_config);
> -- 
> 2.5.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 3/4] ARM: dts: vfxxx: Add OCROM and phandle entries for Vybrid SoC bus driver

[maitysanchayan]

Hello,

On 16-04-01 14:00:46, Shawn Guo wrote:
> On Fri, Mar 11, 2016 at 02:29:30PM +0530, Sanchayan Maity wrote:
> > Add OCROM node and introduce phandles to OCROM, MSCM and NVMEM
> > OCOTP for use by the Vybrid SoC bus driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index db9157e..0dd7ad5 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -87,9 +87,19 @@
> > soc {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > -   compatible = "simple-bus";
> > +   compatible = "fsl,vf610-soc-bus", "simple-bus";
> > interrupt-parent = <_ir>;
> > ranges;
> > +   fsl,rom-revision = < 0x80>;
> > +   fsl,cpu-count = <_cpucfg 0x2C>;
> > +   fsl,l2-size = <_cpucfg 0x14>;
> 
> We need a bindings doc for these new properties and compatible.

Ok. Will add the documentation part in v2.

- Sanchayan.

> 
> Shawn
> 
> > +   nvmem-cells = <_cfg0>, <_cfg1>;
> > +   nvmem-cell-names = "cfg0", "cfg1";
> > +
> > +   ocrom: ocrom@ {
> > +   compatible = "fsl,vf610-ocrom", "syscon";
> > +   reg = <0x 0x18000>;
> > +   };
> >  
> > aips0: aips-bus@4000 {
> > compatible = "fsl,aips-bus", "simple-bus";
> > -- 
> > 2.7.2
> > 
> > 

Re: [PATCH v1 3/4] ARM: dts: vfxxx: Add OCROM and phandle entries for Vybrid SoC bus driver

[maitysanchayan]

Hello,

On 16-04-01 14:00:46, Shawn Guo wrote:
> On Fri, Mar 11, 2016 at 02:29:30PM +0530, Sanchayan Maity wrote:
> > Add OCROM node and introduce phandles to OCROM, MSCM and NVMEM
> > OCOTP for use by the Vybrid SoC bus driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index db9157e..0dd7ad5 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -87,9 +87,19 @@
> > soc {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > -   compatible = "simple-bus";
> > +   compatible = "fsl,vf610-soc-bus", "simple-bus";
> > interrupt-parent = <_ir>;
> > ranges;
> > +   fsl,rom-revision = < 0x80>;
> > +   fsl,cpu-count = <_cpucfg 0x2C>;
> > +   fsl,l2-size = <_cpucfg 0x14>;
> 
> We need a bindings doc for these new properties and compatible.

Ok. Will add the documentation part in v2.

- Sanchayan.

> 
> Shawn
> 
> > +   nvmem-cells = <_cfg0>, <_cfg1>;
> > +   nvmem-cell-names = "cfg0", "cfg1";
> > +
> > +   ocrom: ocrom@ {
> > +   compatible = "fsl,vf610-ocrom", "syscon";
> > +   reg = <0x 0x18000>;
> > +   };
> >  
> > aips0: aips-bus@4000 {
> > compatible = "fsl,aips-bus", "simple-bus";
> > -- 
> > 2.7.2
> > 
> > 

Re: [RFC PATCH 0/4] Implement USB device/host switch for Vybrid

[maitysanchayan]

Hello Peter,

On 16-03-29 00:24:46, Peter Chen wrote:
>  
> > 
> > On 2016-03-25 00:40, Peter Chen wrote:
> > > On Tue, Mar 15, 2016 at 02:08:26PM +0530, Sanchayan Maity wrote:
> > >> Hello Peter,
> > >>
> > >> The existing usage of extcon in Chipidea driver relies on OTG
> > >> registers. In case of SoC with dual role device but not a true OTG
> > >> controller, this does not work. Such SoC's should specify the
> > >> existing CI_HDRC_DUAL_ROLE_NOT_OTG flag and do the role switch
> > >> without checking any of the OTG registers in my opinion.
> > >> This is the case for Vybrid which uses a Chipidea IP but does not
> > >> have a true 5 pin OTG implemented.
> > >
> > > Sorry to reply you late due to my new born baby.
> > >
> > > Are you sure Vybrid is NOT OTG core? Afaik, it is uses the same IP
> > > base with other Freescale SoCs, just the IP core is 2.40a.
> > > When working at device mode, can you read vbus status through OTGSC?
> > > And if there is an ID pin (input pin) for Vybrid? I mean SoC, not the
> > > board.
> > 
> > I think the IP is actually OTG capable, the registers are there, but the 
> > signals
> > seem not to be available on the SoC package. That is also what the RM 
> > says...
> > 
> > Quotes from the RM:
> > 
> > "OTG controller should be treated as
> > Dual role controller that allows the
> > controller to act as either a Host or a
> > device with no support for HNP/SRP."
> > 
> > And later, in Chapter 11.1:
> > 
> > "The USB is not a true OTG. It can be configured by software to function 
> > either
> > as peripheral or as host. The ID pin, which is unique for OTG operation, is 
> > not
> > present in this implementation. There are no five pin interface. The user 
> > will
> > get four pin host/ device interface."
> > 
> 
> Get it, thanks. I am doing a patch for covering this case and vbus always-on 
> case.

If I may ask at this point, how would your implementation be covering this case
for Vybrid?

- Sanchayan.

Re: [RFC PATCH 0/4] Implement USB device/host switch for Vybrid

[maitysanchayan]

Hello Peter,

On 16-03-29 00:24:46, Peter Chen wrote:
>  
> > 
> > On 2016-03-25 00:40, Peter Chen wrote:
> > > On Tue, Mar 15, 2016 at 02:08:26PM +0530, Sanchayan Maity wrote:
> > >> Hello Peter,
> > >>
> > >> The existing usage of extcon in Chipidea driver relies on OTG
> > >> registers. In case of SoC with dual role device but not a true OTG
> > >> controller, this does not work. Such SoC's should specify the
> > >> existing CI_HDRC_DUAL_ROLE_NOT_OTG flag and do the role switch
> > >> without checking any of the OTG registers in my opinion.
> > >> This is the case for Vybrid which uses a Chipidea IP but does not
> > >> have a true 5 pin OTG implemented.
> > >
> > > Sorry to reply you late due to my new born baby.
> > >
> > > Are you sure Vybrid is NOT OTG core? Afaik, it is uses the same IP
> > > base with other Freescale SoCs, just the IP core is 2.40a.
> > > When working at device mode, can you read vbus status through OTGSC?
> > > And if there is an ID pin (input pin) for Vybrid? I mean SoC, not the
> > > board.
> > 
> > I think the IP is actually OTG capable, the registers are there, but the 
> > signals
> > seem not to be available on the SoC package. That is also what the RM 
> > says...
> > 
> > Quotes from the RM:
> > 
> > "OTG controller should be treated as
> > Dual role controller that allows the
> > controller to act as either a Host or a
> > device with no support for HNP/SRP."
> > 
> > And later, in Chapter 11.1:
> > 
> > "The USB is not a true OTG. It can be configured by software to function 
> > either
> > as peripheral or as host. The ID pin, which is unique for OTG operation, is 
> > not
> > present in this implementation. There are no five pin interface. The user 
> > will
> > get four pin host/ device interface."
> > 
> 
> Get it, thanks. I am doing a patch for covering this case and vbus always-on 
> case.

If I may ask at this point, how would your implementation be covering this case
for Vybrid?

- Sanchayan.

Re: [PATCH v1 0/4] Implement SoC bus driver for Vybrid

[maitysanchayan]

Hello,

Ping.

- Sanchayan.

On 16-03-11 14:29:27, Sanchayan Maity wrote:
> Hello,
> 
> This patchset implements SoC bus support for Freescale Vybrid platform,
> implementing the following
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc
> 
> This a reworked version of an older patchset series posted in June 2015
> which was at v5 then [1]. Since the NVMEM framework was then getting
> introduced, we decided that first a NVMEM driver for OCOTP peripheral
> being in place would be better.
> 
> Compared to the older revisions, this driver now relies on NVMEM
> consumer API using the NVMEM based vf610_ocotp driver which has
> already been in mainline for a while now. Also now a new syscon
> abstraction "syscon_regmap_read_from_offset" is implemented and
> exported from syscon allowing accessing a register from a syscon
> reference like this
> 
> ocotp-cfg1 = < 0x20>;
> 
> avoiding code repetition in the driver.
> 
> One point on which we were not sure here is whether we really should
> introduce a new Kconfig symbol as being introduced here. While we
> could just enable it when SOC_VF610 is selected, this however would
> introduce circular dependencies.
> 
> This patch series is based on top of shawn's for-next branch and
> tested on Colibri Vybrid VF50 and VF61 modules.
> 
> Feedback is most welcome.
> 
> [1] Older v5:
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> Even earlier versions:
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Regards,
> Sanchayan.
> 
> Sanchayan Maity (4):
>   mfd: syscon: Introduce syscon_regmap_read_from_offset
>   ARM: dts: vfxxx: Add device tree node for OCOTP
>   ARM: dts: vfxxx: Add OCROM and phandle entries for Vybrid SoC bus driver
>   soc: Add SoC bus driver for Freescale Vybrid Platform
> 
>  arch/arm/boot/dts/vfxxx.dtsi |  28 +++-
>  drivers/mfd/syscon.c |  30 
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/fsl/Kconfig  |  10 +++
>  drivers/soc/fsl/Makefile |   1 +
>  drivers/soc/fsl/soc-vf610.c  | 160 
> +++
>  include/linux/mfd/syscon.h   |  10 +++
>  7 files changed, 239 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/soc-vf610.c
> 
> -- 
> 2.7.2
> 

Re: [PATCH v1 0/4] Implement SoC bus driver for Vybrid

[maitysanchayan]

Hello,

Ping.

- Sanchayan.

On 16-03-11 14:29:27, Sanchayan Maity wrote:
> Hello,
> 
> This patchset implements SoC bus support for Freescale Vybrid platform,
> implementing the following
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-soc
> 
> This a reworked version of an older patchset series posted in June 2015
> which was at v5 then [1]. Since the NVMEM framework was then getting
> introduced, we decided that first a NVMEM driver for OCOTP peripheral
> being in place would be better.
> 
> Compared to the older revisions, this driver now relies on NVMEM
> consumer API using the NVMEM based vf610_ocotp driver which has
> already been in mainline for a while now. Also now a new syscon
> abstraction "syscon_regmap_read_from_offset" is implemented and
> exported from syscon allowing accessing a register from a syscon
> reference like this
> 
> ocotp-cfg1 = < 0x20>;
> 
> avoiding code repetition in the driver.
> 
> One point on which we were not sure here is whether we really should
> introduce a new Kconfig symbol as being introduced here. While we
> could just enable it when SOC_VF610 is selected, this however would
> introduce circular dependencies.
> 
> This patch series is based on top of shawn's for-next branch and
> tested on Colibri Vybrid VF50 and VF61 modules.
> 
> Feedback is most welcome.
> 
> [1] Older v5:
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> Even earlier versions:
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Regards,
> Sanchayan.
> 
> Sanchayan Maity (4):
>   mfd: syscon: Introduce syscon_regmap_read_from_offset
>   ARM: dts: vfxxx: Add device tree node for OCOTP
>   ARM: dts: vfxxx: Add OCROM and phandle entries for Vybrid SoC bus driver
>   soc: Add SoC bus driver for Freescale Vybrid Platform
> 
>  arch/arm/boot/dts/vfxxx.dtsi |  28 +++-
>  drivers/mfd/syscon.c |  30 
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/fsl/Kconfig  |  10 +++
>  drivers/soc/fsl/Makefile |   1 +
>  drivers/soc/fsl/soc-vf610.c  | 160 
> +++
>  include/linux/mfd/syscon.h   |  10 +++
>  7 files changed, 239 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/soc/fsl/Kconfig
>  create mode 100644 drivers/soc/fsl/soc-vf610.c
> 
> -- 
> 2.7.2
> 

Re: [PATCH v2] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

[maitysanchayan]

Hello Shawn,

On 16-02-14 16:33:49, Shawn Guo wrote:
> On Fri, Feb 12, 2016 at 05:53:00PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid as
> > hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> > 
> > Hello,
> > 
> > The first version of the patch was send quite a while ago.
> > https://lkml.org/lkml/2015/9/16/932
> > 
> > Shawn you had requested that hyphen rather than underscore should
> > be used in node name. I looked into that.
> > 
> > The iio_hwmon driver calls hwmon_device register_with_groups inside
> > hwmon.c and this
> > http://lxr.free-electrons.com/source/drivers/hwmon/hwmon.c#L103
> > 
> > does not allow hyphen in hwmon name attribute. I was not aware of
> > this but while trying to test the change, the device probe failed
> > with EINVAL. I think we should stick to the existing use of the
> > bindings or we need to change the hwmon code as well along with the
> > existing device tree files and binding documentation.
> 
> I disagree.
> 
> If hyphen is invalid to be part of hwmon name attribute, the following
> code in iio_hwmon_probe() is plain wrong, because hyphen is very valid
> to be part of node names in device tree.
> 
> if (dev->of_node && dev->of_node->name)
> name = dev->of_node->name;

@Shawn
I agree with what you state here, however as you can see the hwmon_device_
register_with_groups does check for hypen with strpbrk and returns EINVAL.
Changing to hyphen instead of currently present underscore in iio_hwmon
node name causes probe failure.

If the node name needs to have hyphen, then the check for hyphen as an invalid
character in hwmon name attribute needs to be changed. I am CC'ing the hwmon
subsystem maintainers Jean Delvare ands Guenter Roeck as well as hwmon list to
check.

@Jean & Guenter
Can you please comment if the change to hwmon_device_register_with_groups
to accept hyphen as a valid character in hwmon name attribute will be 
acceptable?
Sorry if this is sudden andfor bringing you late into the discussion Jean and
Guenter.

Thanks & Regards,
Sanchayan.

> 
> Shawn
> 
> > 
> > Changes since v1:
> > 1. Expose ADC1 temperature channel as well
> > 2. Move the entry outside of the aips1 bus node
> > 
> > Best Regards,
> > Sanchayan Maity.
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index a5f07e3..8ed8e47 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -673,5 +673,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   iio_hwmon {
> > +   compatible = "iio-hwmon";
> > +   io-channels = < 16>, < 16>;
> > +   };
> > };
> >  };
> > -- 
> > 2.7.1
> > 
> > 

Re: [PATCH v2] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

[maitysanchayan]

Hello Shawn,

On 16-02-14 16:33:49, Shawn Guo wrote:
> On Fri, Feb 12, 2016 at 05:53:00PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid as
> > hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> > 
> > Hello,
> > 
> > The first version of the patch was send quite a while ago.
> > https://lkml.org/lkml/2015/9/16/932
> > 
> > Shawn you had requested that hyphen rather than underscore should
> > be used in node name. I looked into that.
> > 
> > The iio_hwmon driver calls hwmon_device register_with_groups inside
> > hwmon.c and this
> > http://lxr.free-electrons.com/source/drivers/hwmon/hwmon.c#L103
> > 
> > does not allow hyphen in hwmon name attribute. I was not aware of
> > this but while trying to test the change, the device probe failed
> > with EINVAL. I think we should stick to the existing use of the
> > bindings or we need to change the hwmon code as well along with the
> > existing device tree files and binding documentation.
> 
> I disagree.
> 
> If hyphen is invalid to be part of hwmon name attribute, the following
> code in iio_hwmon_probe() is plain wrong, because hyphen is very valid
> to be part of node names in device tree.
> 
> if (dev->of_node && dev->of_node->name)
> name = dev->of_node->name;

@Shawn
I agree with what you state here, however as you can see the hwmon_device_
register_with_groups does check for hypen with strpbrk and returns EINVAL.
Changing to hyphen instead of currently present underscore in iio_hwmon
node name causes probe failure.

If the node name needs to have hyphen, then the check for hyphen as an invalid
character in hwmon name attribute needs to be changed. I am CC'ing the hwmon
subsystem maintainers Jean Delvare ands Guenter Roeck as well as hwmon list to
check.

@Jean & Guenter
Can you please comment if the change to hwmon_device_register_with_groups
to accept hyphen as a valid character in hwmon name attribute will be 
acceptable?
Sorry if this is sudden andfor bringing you late into the discussion Jean and
Guenter.

Thanks & Regards,
Sanchayan.

> 
> Shawn
> 
> > 
> > Changes since v1:
> > 1. Expose ADC1 temperature channel as well
> > 2. Move the entry outside of the aips1 bus node
> > 
> > Best Regards,
> > Sanchayan Maity.
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index a5f07e3..8ed8e47 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -673,5 +673,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   iio_hwmon {
> > +   compatible = "iio-hwmon";
> > +   io-channels = < 16>, < 16>;
> > +   };
> > };
> >  };
> > -- 
> > 2.7.1
> > 
> > 

Re: touchscreen: edt-ft5x06: Prevent DMA driver from mapping an area on stack

[maitysanchayan]

Hello,

On 15-12-12 20:42:37, Dmitry Torokhov wrote:
> On Sat, Dec 12, 2015 at 06:13:55PM +0100, Wolfram Sang wrote:
> > 
> > > Frankly speaking I do not know where the fix should actually be. I2C IMX
> > > driver somehow taking care of this or the users of I2C, touchscreen 
> > > drivers
> > > in this case. In my opinion, the fix should be with the touchscreen driver
> > > however I did like to have feedback or hear opinions on what is the 
> > > accepted
> > > solution to this.
> > 
> > There is no accepted solution to this yet :( DMA is/was still too rare for
> > a serious discussion about this. There is also [1] and probably more...
> > 
> > [1]  http://patchwork.ozlabs.org/patch/220137/
> 
> I believe vast majority of i2c client drivers do not expect that the
> transfer buffer they supply in i2c messages are supposed to be DMAable
> (unlike USB and SPI buses that had that requirement from the beginning).
> 
> I won't be applying this patch unless we decide that I2C changes the
> rules.

Understood. Thanks for the clarifications Dmitry and Wolfram.

- Sanchayan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: touchscreen: edt-ft5x06: Prevent DMA driver from mapping an area on stack

[maitysanchayan]

Hello,

On 15-12-12 20:42:37, Dmitry Torokhov wrote:
> On Sat, Dec 12, 2015 at 06:13:55PM +0100, Wolfram Sang wrote:
> > 
> > > Frankly speaking I do not know where the fix should actually be. I2C IMX
> > > driver somehow taking care of this or the users of I2C, touchscreen 
> > > drivers
> > > in this case. In my opinion, the fix should be with the touchscreen driver
> > > however I did like to have feedback or hear opinions on what is the 
> > > accepted
> > > solution to this.
> > 
> > There is no accepted solution to this yet :( DMA is/was still too rare for
> > a serious discussion about this. There is also [1] and probably more...
> > 
> > [1]  http://patchwork.ozlabs.org/patch/220137/
> 
> I believe vast majority of i2c client drivers do not expect that the
> transfer buffer they supply in i2c messages are supposed to be DMAable
> (unlike USB and SPI buses that had that requirement from the beginning).
> 
> I won't be applying this patch unless we decide that I2C changes the
> rules.

Understood. Thanks for the clarifications Dmitry and Wolfram.

- Sanchayan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: vfxxx: Fix erroneous property in esdhc0 node

[maitysanchayan]

Ping?

On 15-10-18 11:18:48, Sanchayan Maity wrote:
> Something seems to have gone wrong during the merging of the device
> tree changes with the following patch
> 
> "ARM: dts: add property for maximum ADC clock frequencies"
> 
> The property "fsl,adck-max-frequency" instead of being applied for
> the ADC1 node got applied to the esdhc0 node. This patch fixes it.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 6736bae..a64bfe1 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -461,6 +461,8 @@
>   clock-names = "adc";
>   #io-channel-cells = <1>;
>   status = "disabled";
> + fsl,adck-max-frequency = <3000>, <4000>,
> + <2000>;
>   };
>  
>   esdhc0: esdhc@400b1000 {
> @@ -472,8 +474,6 @@
>   < VF610_CLK_ESDHC0>;
>   clock-names = "ipg", "ahb", "per";
>   status = "disabled";
> - fsl,adck-max-frequency = <3000>, <4000>,
> - <2000>;
>   };
>  
>   esdhc1: esdhc@400b2000 {
> -- 
> 2.6.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: vfxxx: Fix erroneous property in esdhc0 node

[maitysanchayan]

Ping?

On 15-10-18 11:18:48, Sanchayan Maity wrote:
> Something seems to have gone wrong during the merging of the device
> tree changes with the following patch
> 
> "ARM: dts: add property for maximum ADC clock frequencies"
> 
> The property "fsl,adck-max-frequency" instead of being applied for
> the ADC1 node got applied to the esdhc0 node. This patch fixes it.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 6736bae..a64bfe1 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -461,6 +461,8 @@
>   clock-names = "adc";
>   #io-channel-cells = <1>;
>   status = "disabled";
> + fsl,adck-max-frequency = <3000>, <4000>,
> + <2000>;
>   };
>  
>   esdhc0: esdhc@400b1000 {
> @@ -472,8 +474,6 @@
>   < VF610_CLK_ESDHC0>;
>   clock-names = "ipg", "ahb", "per";
>   status = "disabled";
> - fsl,adck-max-frequency = <3000>, <4000>,
> - <2000>;
>   };
>  
>   esdhc1: esdhc@400b2000 {
> -- 
> 2.6.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[maitysanchayan]

Hello Shawn,

The driver has landed in your tree. Can you queue this DT change for the same?

Thanks.

- Sanchayan.

On 15-09-01 18:06:53, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  5 +++
>  arch/arm/boot/dts/vf500-colibri.dtsi| 47 
> +
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c3173fc 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,8 @@
>   model = "Toradex Colibri VF50 on Colibri Evaluation Board";
>   compatible = "toradex,vf500-colibri_vf50-on-eval", 
> "toradex,vf500-colibri_vf50", "fsl,vf500";
>  };
> +
> + {
> + vf50-ts-min-pressure = <200>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi 
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..84f091d 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,51 @@
>   memory {
>   reg = <0x8000 0x800>;
>   };
> +
> + touchscreen: vf50-touchscreen {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = < 0>,< 0>,
> + < 1>,< 2>;
> + xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <_touchctrl_idle>;
> + pinctrl-1 = <_touchctrl_default>;
> + pinctrl-2 = <_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
> + status = "disabled";
> + };
> +};
> +
> + {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x006d
> + VF610_PAD_PTA19__GPIO_9 0x006c
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0   0x0040
> + VF610_PAD_PTA19__ADC0_SE1   0x0040
> + VF610_PAD_PTA16__ADC1_SE0   0x0040
> + VF610_PAD_PTB2__ADC1_SE20x0040
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22e9
> + VF610_PAD_PTB23__GPIO_930x22e9
> + VF610_PAD_PTA22__GPIO_120x22e9
> + VF610_PAD_PTA11__GPIO_4 0x22e9
> + >;
> + };
> + };
>  };
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[maitysanchayan]

Hello Shawn,

The driver has landed in your tree. Can you queue this DT change for the same?

Thanks.

- Sanchayan.

On 15-09-01 18:06:53, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  5 +++
>  arch/arm/boot/dts/vf500-colibri.dtsi| 47 
> +
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c3173fc 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,8 @@
>   model = "Toradex Colibri VF50 on Colibri Evaluation Board";
>   compatible = "toradex,vf500-colibri_vf50-on-eval", 
> "toradex,vf500-colibri_vf50", "fsl,vf500";
>  };
> +
> + {
> + vf50-ts-min-pressure = <200>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi 
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..84f091d 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,51 @@
>   memory {
>   reg = <0x8000 0x800>;
>   };
> +
> + touchscreen: vf50-touchscreen {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = < 0>,< 0>,
> + < 1>,< 2>;
> + xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <_touchctrl_idle>;
> + pinctrl-1 = <_touchctrl_default>;
> + pinctrl-2 = <_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
> + status = "disabled";
> + };
> +};
> +
> + {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x006d
> + VF610_PAD_PTA19__GPIO_9 0x006c
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0   0x0040
> + VF610_PAD_PTA19__ADC0_SE1   0x0040
> + VF610_PAD_PTA16__ADC1_SE0   0x0040
> + VF610_PAD_PTB2__ADC1_SE20x0040
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22e9
> + VF610_PAD_PTB23__GPIO_930x22e9
> + VF610_PAD_PTA22__GPIO_120x22e9
> + VF610_PAD_PTA11__GPIO_4 0x22e9
> + >;
> + };
> + };
>  };
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 15-09-07 13:51:34, Sanchayan Maity wrote:
> Hello,
> 
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-9-g1cec223 #5 SMP Mon Sep 7 12:34:37 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2006      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1300      
> 8d0 320a 0800      
> 8e0  e200      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> Changes since v9:
> 1. Drop clock-names property from DT
> 2. Rebase on top of latest char-misc-next
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Version 9 patches can be found here
> https://lkml.org/lkml/2015/8/12/530
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  19 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   8 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 344 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
>  create mode 100644 drivers/nvmem/vf610-ocotp.c
> 
> -- 
> 2.5.1
> 
--
To unsubscribe from this list: 

Re: [PATCH v10 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 15-09-07 13:51:34, Sanchayan Maity wrote:
> Hello,
> 
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-9-g1cec223 #5 SMP Mon Sep 7 12:34:37 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2006      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1300      
> 8d0 320a 0800      
> 8e0  e200      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> Changes since v9:
> 1. Drop clock-names property from DT
> 2. Rebase on top of latest char-misc-next
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Version 9 patches can be found here
> https://lkml.org/lkml/2015/8/12/530
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  19 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   8 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 344 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
>  create mode 100644 drivers/nvmem/vf610-ocotp.c
> 
> -- 
> 2.5.1
> 
--
To unsubscribe from this list: 

Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

[maitysanchayan]

Hi Shawn,

On 15-09-06 12:32:32, Shawn Guo wrote:
> On Thu, Aug 06, 2015 at 09:28:22PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid
> > as hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 39173bb..0993d66 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -597,5 +597,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   iio_hwmon {
> 
> Hyphen rather than underscore should be used in node name.

As per iio-bindings.txt I did this. It is the same in imx23.dtsi and imx28.dtsi.

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/iio/iio-bindings.txt#L85
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx23.dtsi#L570
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx28.dtsi#L1246

So should this be changed?

Thanks.

- Sanchayan.

> 
> Shawn
> 
> > +   compatible = "iio-hwmon";
> > +   io-channels = < 16>;
> > +   };
> > };
> >  };
> > -- 
> > 2.5.0
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

[maitysanchayan]

Hi Shawn,

On 15-09-06 12:32:32, Shawn Guo wrote:
> On Thu, Aug 06, 2015 at 09:28:22PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid
> > as hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 39173bb..0993d66 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -597,5 +597,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   iio_hwmon {
> 
> Hyphen rather than underscore should be used in node name.

As per iio-bindings.txt I did this. It is the same in imx23.dtsi and imx28.dtsi.

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/iio/iio-bindings.txt#L85
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx23.dtsi#L570
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx28.dtsi#L1246

So should this be changed?

Thanks.

- Sanchayan.

> 
> Shawn
> 
> > +   compatible = "iio-hwmon";
> > +   io-channels = < 16>;
> > +   };
> > };
> >  };
> > -- 
> > 2.5.0
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver

[maitysanchayan]

On 15-09-06 16:13:35, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:21PM +0530, Sanchayan Maity wrote:
> > Add the devicetree bindings for the Freescale Vybrid On-Chip
> > OTP driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > Acked-by: Srinivas Kandagatla 
> > ---
> >  .../devicetree/bindings/nvmem/vf610-ocotp.txt   | 21 
> > +
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt 
> > b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > new file mode 100644
> > index 000..b29f65f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > @@ -0,0 +1,21 @@
> > +On-Chip OTP Memory for Freescale Vybrid
> > +
> > +Required Properties:
> > +  compatible:
> > +  - "fsl,vf610-ocotp" for VF5xx/VF6xx
> > +  #address-cells : Should be 1
> > +  #size-cells : Should be 1
> > +  reg : Address and length of OTP controller and fuse map registers
> > +  clocks : ipg clock we associate with the OCOTP peripheral
> > +  clock-names : Must contain "ocotp" as matching entry
> 
> I'm not sure "ocotp" is a good name for describing a clock from OCOTP
> internal point of view.  "ipg" might be better.  But I would suggest you
> drop clock-names property completely, if "ipg" is the only clock you
> need to describe here.  The clock-names is necessary only when there are
> multiple clocks to distinguish.
> 
> With clock-names dropped, the driver works by passing NULL as the second
> parameter to devm_clk_get() call.

Ok. Will drop the clock-names property retest and try sending it by tomorrow.

- Sanchayan.

> 
> Shawn
> 
> > +
> > +Example for Vybrid VF5xx/VF6xx:
> > +
> > +   ocotp: ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xCF0>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +   clock-names = "ocotp";
> > +   };
> > -- 
> > 2.5.0
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 1/4] clk: clk-vf610: Add clock for Vybrid OCOTP controller

[maitysanchayan]

On 15-09-06 16:15:26, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:18PM +0530, Sanchayan Maity wrote:
> > Add clock support for Vybrid On-Chip One Time Programmable
> > (OCOTP) controller.
> > 
> > While the OCOTP block does not require explicit clock gating,
> > for programming the OCOTP timing register the clock rate of
> > ipg clock is required for timing calculations related to fuse
> > and shadow register read sequence. We explicitly specify the
> > ipg clock for OCOTP as a result.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/clk/imx/clk-vf610.c | 1 +
> >  include/dt-bindings/clock/vf610-clock.h | 3 ++-
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> Please copy linux-clk list and clock maintainers on i.MX clock patches
> as well.  If you run ./scripts/get_maintainer.pl on the patch, you will
> get them.

Ok. Will take care of this with the next version. Thanks.

- Sanchayan.

> 
> Shawn
> 
> > 
> > diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> > index bff45ea..d1b1c95 100644
> > --- a/drivers/clk/imx/clk-vf610.c
> > +++ b/drivers/clk/imx/clk-vf610.c
> > @@ -387,6 +387,7 @@ static void __init vf610_clocks_init(struct device_node 
> > *ccm_node)
> >  
> > clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(7));
> > clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR, 24);
> > +   clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(5));
> >  
> > imx_check_clocks(clk, ARRAY_SIZE(clk));
> >  
> > diff --git a/include/dt-bindings/clock/vf610-clock.h 
> > b/include/dt-bindings/clock/vf610-clock.h
> > index d197634..56c16aa 100644
> > --- a/include/dt-bindings/clock/vf610-clock.h
> > +++ b/include/dt-bindings/clock/vf610-clock.h
> > @@ -194,6 +194,7 @@
> >  #define VF610_PLL7_BYPASS  181
> >  #define VF610_CLK_SNVS 182
> >  #define VF610_CLK_DAP  183
> > -#define VF610_CLK_END  184
> > +#define VF610_CLK_OCOTP 184
> > +#define VF610_CLK_END  185
> >  
> >  #endif /* __DT_BINDINGS_CLOCK_VF610_H */
> > -- 
> > 2.5.0
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 1/4] clk: clk-vf610: Add clock for Vybrid OCOTP controller

[maitysanchayan]

On 15-09-06 16:15:26, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:18PM +0530, Sanchayan Maity wrote:
> > Add clock support for Vybrid On-Chip One Time Programmable
> > (OCOTP) controller.
> > 
> > While the OCOTP block does not require explicit clock gating,
> > for programming the OCOTP timing register the clock rate of
> > ipg clock is required for timing calculations related to fuse
> > and shadow register read sequence. We explicitly specify the
> > ipg clock for OCOTP as a result.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/clk/imx/clk-vf610.c | 1 +
> >  include/dt-bindings/clock/vf610-clock.h | 3 ++-
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> Please copy linux-clk list and clock maintainers on i.MX clock patches
> as well.  If you run ./scripts/get_maintainer.pl on the patch, you will
> get them.

Ok. Will take care of this with the next version. Thanks.

- Sanchayan.

> 
> Shawn
> 
> > 
> > diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> > index bff45ea..d1b1c95 100644
> > --- a/drivers/clk/imx/clk-vf610.c
> > +++ b/drivers/clk/imx/clk-vf610.c
> > @@ -387,6 +387,7 @@ static void __init vf610_clocks_init(struct device_node 
> > *ccm_node)
> >  
> > clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(7));
> > clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR, 24);
> > +   clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6, 
> > CCM_CCGRx_CGn(5));
> >  
> > imx_check_clocks(clk, ARRAY_SIZE(clk));
> >  
> > diff --git a/include/dt-bindings/clock/vf610-clock.h 
> > b/include/dt-bindings/clock/vf610-clock.h
> > index d197634..56c16aa 100644
> > --- a/include/dt-bindings/clock/vf610-clock.h
> > +++ b/include/dt-bindings/clock/vf610-clock.h
> > @@ -194,6 +194,7 @@
> >  #define VF610_PLL7_BYPASS  181
> >  #define VF610_CLK_SNVS 182
> >  #define VF610_CLK_DAP  183
> > -#define VF610_CLK_END  184
> > +#define VF610_CLK_OCOTP 184
> > +#define VF610_CLK_END  185
> >  
> >  #endif /* __DT_BINDINGS_CLOCK_VF610_H */
> > -- 
> > 2.5.0
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver

[maitysanchayan]

On 15-09-06 16:13:35, Shawn Guo wrote:
> On Wed, Aug 12, 2015 at 06:49:21PM +0530, Sanchayan Maity wrote:
> > Add the devicetree bindings for the Freescale Vybrid On-Chip
> > OTP driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > Acked-by: Srinivas Kandagatla 
> > ---
> >  .../devicetree/bindings/nvmem/vf610-ocotp.txt   | 21 
> > +
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt 
> > b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > new file mode 100644
> > index 000..b29f65f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > @@ -0,0 +1,21 @@
> > +On-Chip OTP Memory for Freescale Vybrid
> > +
> > +Required Properties:
> > +  compatible:
> > +  - "fsl,vf610-ocotp" for VF5xx/VF6xx
> > +  #address-cells : Should be 1
> > +  #size-cells : Should be 1
> > +  reg : Address and length of OTP controller and fuse map registers
> > +  clocks : ipg clock we associate with the OCOTP peripheral
> > +  clock-names : Must contain "ocotp" as matching entry
> 
> I'm not sure "ocotp" is a good name for describing a clock from OCOTP
> internal point of view.  "ipg" might be better.  But I would suggest you
> drop clock-names property completely, if "ipg" is the only clock you
> need to describe here.  The clock-names is necessary only when there are
> multiple clocks to distinguish.
> 
> With clock-names dropped, the driver works by passing NULL as the second
> parameter to devm_clk_get() call.

Ok. Will drop the clock-names property retest and try sending it by tomorrow.

- Sanchayan.

> 
> Shawn
> 
> > +
> > +Example for Vybrid VF5xx/VF6xx:
> > +
> > +   ocotp: ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xCF0>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +   clock-names = "ocotp";
> > +   };
> > -- 
> > 2.5.0
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hi,

On 15-09-04 09:21:04, Srinivas Kandagatla wrote:
> Hi Sanchayan,
> 
> On 04/09/15 06:50, maitysancha...@gmail.com wrote:
> > Hello,
> >
> > Ping? Anything preventing this from being accepted? I can rework it then if
> > so.
> Thanks for your patience,
> 
> We are in the middle of merge window, I will pick the driver for 4.4 
> after 4.3-rc1 is released for linux-next testing.

Thank you very much for the update Srinivas.

- Sanchayan.

> 
> --srini
> 
> >
> > Thanks.
> >
> > - Sanchayan.
> >
> > On 15-08-12 18:49:17, Sanchayan Maity wrote:
> >> Hello,
> >>
> >> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> >> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> >> patchset.
> >>
> >> Sample output on Colibri VF50
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> >> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 
> >> 2015 armv7l GNU/Linux
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> >> 000        
> >> *
> >> 410 72a6 df64      
> >> 420 11d4 2c14      
> >> 430        
> >> *
> >> 450 0280       
> >> 460        
> >> *
> >> 880 8f01       
> >> 890        
> >> *
> >> 8c0  1000      
> >> 8d0 3202 0800      
> >> 8e0  e100      
> >> 8f0        
> >> *
> >> c80 bada bada      
> >> *
> >> cc0        
> >> *
> >> cf0
> >>
> >> The driver has changed quite a bit from the first version
> >> relying on of_platform_populate in mach file, to using
> >> SoC driver under drivers/soc and finally to NVMEM.
> >>
> >> Feedback and comments most welcome.
> >>
> >> Version 8 patches can be found here
> >> https://lkml.org/lkml/2015/8/10/566
> >>
> >> Version 7 patches can be found here
> >> https://lkml.org/lkml/2015/8/6/440
> >>
> >> Version 6 RFC patches can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> >>
> >> Version 5 of the patchset can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> >>
> >> Version 4 of the patchset can be found here
> >> https://lkml.org/lkml/2015/5/26/199
> >>
> >> Version 3 of the patchset can be found here
> >> http://www.spinics.net/lists/arm-kernel/msg420847.html
> >>
> >> Version 2 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80654.html
> >>
> >> Version 1 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80257.html
> >>
> >> The RFC version can be found here
> >> https://lkml.org/lkml/2015/5/11/13
> >>
> >> Changes since v8:
> >> 1. Fix three lines over 80 characters
> >> 2. Rebase on top of Greg's char-misc-next branch
> >>
> >> Changes since v7:
> >> 1. Add COMPILE_TEST to Kconfig
> >> 2. Use GENMASK and BIT macros where applicable
> >> 3. Fix a code alignment issue
> >> 4. Get the max_register value for regmap config using
> >> resource_size()
> >> 5. Also add copyright info as the driver logic is based off
> >> on ocotp code in barebox
> >> 6. Add missing info related to clock in DT binding doc
> >>
> >> Changes since v6:
> >> 1. Use the v9 of NVMEM framework patchset
> >> 2. Add a few comments
> >> 3. Initialise buffer address not part of the fuse map to 0
> >> instead of only handling buffer locations with valid fuse
> >> addresses.
> >>
> >> Changes since v5:
> >> Use NVMEM framework by Srinivas and Maxime
> >>
> >> Changes since v4:
> >> 1. Use devm_* family of functions and use a struct to get rid of
> >> global variables (suggested by Joachim Eastwood)
> >> 2. Make Kconfig govern the compilation with tristate, instead of
> >> earlier bool. Paul Bolle raised a valid point that perhaps this
> >> should have been built in with the bool, however I had not taken
> >> into consideration generic distro kernels and it makes sense to
> >> have this tristated. (comments from Paul Bolle and Andreas Farber)
> >>
> >> Changes since v3:
> >> Instead of using the syscon_regmap_lookup_by_compatible function
> >> use a phandle in the device tree along with offsets specified in
> >> this phandle node and then read the offset along with the device
> >> node in the driver for reading from the required region.
> >>
> >> Changes since v2:
> >> Implement the SoC bus code as a driver in drivers/soc
> >> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> >>
> >> Changes since v1:
> >> Sort the headers in alphabetical order
> >>
> >> Changes since RFC:
> >> Use a DT entry for the ROM area while specifying it as syscon.
> >>
> >> Thanks & Regards,
> >> Sanchayan Maity.
> >>
> 

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hi,

On 15-09-04 09:21:04, Srinivas Kandagatla wrote:
> Hi Sanchayan,
> 
> On 04/09/15 06:50, maitysancha...@gmail.com wrote:
> > Hello,
> >
> > Ping? Anything preventing this from being accepted? I can rework it then if
> > so.
> Thanks for your patience,
> 
> We are in the middle of merge window, I will pick the driver for 4.4 
> after 4.3-rc1 is released for linux-next testing.

Thank you very much for the update Srinivas.

- Sanchayan.

> 
> --srini
> 
> >
> > Thanks.
> >
> > - Sanchayan.
> >
> > On 15-08-12 18:49:17, Sanchayan Maity wrote:
> >> Hello,
> >>
> >> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> >> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> >> patchset.
> >>
> >> Sample output on Colibri VF50
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> >> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 
> >> 2015 armv7l GNU/Linux
> >>
> >> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> >> 000        
> >> *
> >> 410 72a6 df64      
> >> 420 11d4 2c14      
> >> 430        
> >> *
> >> 450 0280       
> >> 460        
> >> *
> >> 880 8f01       
> >> 890        
> >> *
> >> 8c0  1000      
> >> 8d0 3202 0800      
> >> 8e0  e100      
> >> 8f0        
> >> *
> >> c80 bada bada      
> >> *
> >> cc0        
> >> *
> >> cf0
> >>
> >> The driver has changed quite a bit from the first version
> >> relying on of_platform_populate in mach file, to using
> >> SoC driver under drivers/soc and finally to NVMEM.
> >>
> >> Feedback and comments most welcome.
> >>
> >> Version 8 patches can be found here
> >> https://lkml.org/lkml/2015/8/10/566
> >>
> >> Version 7 patches can be found here
> >> https://lkml.org/lkml/2015/8/6/440
> >>
> >> Version 6 RFC patches can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> >>
> >> Version 5 of the patchset can be found here
> >> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> >>
> >> Version 4 of the patchset can be found here
> >> https://lkml.org/lkml/2015/5/26/199
> >>
> >> Version 3 of the patchset can be found here
> >> http://www.spinics.net/lists/arm-kernel/msg420847.html
> >>
> >> Version 2 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80654.html
> >>
> >> Version 1 of the patchset can be found here
> >> http://www.spinics.net/lists/devicetree/msg80257.html
> >>
> >> The RFC version can be found here
> >> https://lkml.org/lkml/2015/5/11/13
> >>
> >> Changes since v8:
> >> 1. Fix three lines over 80 characters
> >> 2. Rebase on top of Greg's char-misc-next branch
> >>
> >> Changes since v7:
> >> 1. Add COMPILE_TEST to Kconfig
> >> 2. Use GENMASK and BIT macros where applicable
> >> 3. Fix a code alignment issue
> >> 4. Get the max_register value for regmap config using
> >> resource_size()
> >> 5. Also add copyright info as the driver logic is based off
> >> on ocotp code in barebox
> >> 6. Add missing info related to clock in DT binding doc
> >>
> >> Changes since v6:
> >> 1. Use the v9 of NVMEM framework patchset
> >> 2. Add a few comments
> >> 3. Initialise buffer address not part of the fuse map to 0
> >> instead of only handling buffer locations with valid fuse
> >> addresses.
> >>
> >> Changes since v5:
> >> Use NVMEM framework by Srinivas and Maxime
> >>
> >> Changes since v4:
> >> 1. Use devm_* family of functions and use a struct to get rid of
> >> global variables (suggested by Joachim Eastwood)
> >> 2. Make Kconfig govern the compilation with tristate, instead of
> >> earlier bool. Paul Bolle raised a valid point that perhaps this
> >> should have been built in with the bool, however I had not taken
> >> into consideration generic distro kernels and it makes sense to
> >> have this tristated. (comments from Paul Bolle and Andreas Farber)
> >>
> >> Changes since v3:
> >> Instead of using the syscon_regmap_lookup_by_compatible function
> >> use a phandle in the device tree along with offsets specified in
> >> this phandle node and then read the offset along with the device
> >> node in the driver for reading from the required region.
> >>
> >> Changes since v2:
> >> Implement the SoC bus code as a driver in drivers/soc
> >> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> >>
> >> Changes since v1:
> >> Sort the headers in alphabetical order
> >>
> >> Changes since RFC:
> >> Use a DT entry for the ROM area while specifying it as syscon.
> >>
> >> Thanks & Regards,
> >> Sanchayan Maity.
> >>
> 

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping? Anything preventing this from being accepted? I can rework it then if
so.

Thanks.

- Sanchayan.

On 15-08-12 18:49:17, Sanchayan Maity wrote:
> Hello,
> 
> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2c14      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1000      
> 8d0 3202 0800      
> 8e0  e100      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> The driver has changed quite a bit from the first version
> relying on of_platform_populate in mach file, to using
> SoC driver under drivers/soc and finally to NVMEM.
> 
> Feedback and comments most welcome.
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  21 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   9 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 347 insertions(+), 1 

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping? Anything preventing this from being accepted? I can rework it then if
so.

Thanks.

- Sanchayan.

On 15-08-12 18:49:17, Sanchayan Maity wrote:
> Hello,
> 
> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2c14      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1000      
> 8d0 3202 0800      
> 8e0  e100      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> The driver has changed quite a bit from the first version
> relying on of_platform_populate in mach file, to using
> SoC driver under drivers/soc and finally to NVMEM.
> 
> Feedback and comments most welcome.
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  21 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   9 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 347 insertions(+), 1 

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping? Any feedback? Is this good to be merged?

Thanks.

- Sanchayan.

On 15-08-12 18:49:17, Sanchayan Maity wrote:
> Hello,
> 
> This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
> Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
> patchset.
> 
> Sample output on Colibri VF50
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
> Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 2015 
> armv7l GNU/Linux
> 
> root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
> 000        
> *
> 410 72a6 df64      
> 420 11d4 2c14      
> 430        
> *
> 450 0280       
> 460        
> *
> 880 8f01       
> 890        
> *
> 8c0  1000      
> 8d0 3202 0800      
> 8e0  e100      
> 8f0        
> *
> c80 bada bada      
> *
> cc0        
> *
> cf0
> 
> The driver has changed quite a bit from the first version
> relying on of_platform_populate in mach file, to using
> SoC driver under drivers/soc and finally to NVMEM.
> 
> Feedback and comments most welcome.
> 
> Version 8 patches can be found here
> https://lkml.org/lkml/2015/8/10/566
> 
> Version 7 patches can be found here
> https://lkml.org/lkml/2015/8/6/440
> 
> Version 6 RFC patches can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
> 
> Version 5 of the patchset can be found here
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
> 
> Version 4 of the patchset can be found here
> https://lkml.org/lkml/2015/5/26/199
> 
> Version 3 of the patchset can be found here
> http://www.spinics.net/lists/arm-kernel/msg420847.html
> 
> Version 2 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80654.html
> 
> Version 1 of the patchset can be found here
> http://www.spinics.net/lists/devicetree/msg80257.html
> 
> The RFC version can be found here
> https://lkml.org/lkml/2015/5/11/13
> 
> Changes since v8:
> 1. Fix three lines over 80 characters
> 2. Rebase on top of Greg's char-misc-next branch
> 
> Changes since v7:
> 1. Add COMPILE_TEST to Kconfig
> 2. Use GENMASK and BIT macros where applicable
> 3. Fix a code alignment issue
> 4. Get the max_register value for regmap config using
> resource_size()
> 5. Also add copyright info as the driver logic is based off
> on ocotp code in barebox
> 6. Add missing info related to clock in DT binding doc
> 
> Changes since v6:
> 1. Use the v9 of NVMEM framework patchset
> 2. Add a few comments
> 3. Initialise buffer address not part of the fuse map to 0
> instead of only handling buffer locations with valid fuse
> addresses.
> 
> Changes since v5:
> Use NVMEM framework by Srinivas and Maxime
> 
> Changes since v4:
> 1. Use devm_* family of functions and use a struct to get rid of
> global variables (suggested by Joachim Eastwood)
> 2. Make Kconfig govern the compilation with tristate, instead of
> earlier bool. Paul Bolle raised a valid point that perhaps this
> should have been built in with the bool, however I had not taken
> into consideration generic distro kernels and it makes sense to
> have this tristated. (comments from Paul Bolle and Andreas Farber)
> 
> Changes since v3:
> Instead of using the syscon_regmap_lookup_by_compatible function
> use a phandle in the device tree along with offsets specified in
> this phandle node and then read the offset along with the device
> node in the driver for reading from the required region.
> 
> Changes since v2:
> Implement the SoC bus code as a driver in drivers/soc
> by registering with fsl,mscm-cpucfg as per Arnd's feedback
> 
> Changes since v1:
> Sort the headers in alphabetical order
> 
> Changes since RFC:
> Use a DT entry for the ROM area while specifying it as syscon.
> 
> Thanks & Regards,
> Sanchayan Maity.
> 
> Sanchayan Maity (4):
>   clk: clk-vf610: Add clock for Vybrid OCOTP controller
>   ARM: dts: vfxxx: Add OCOTP node
>   drivers: nvmem: Add Vybrid OCOTP support
>   nvmem: Add DT binding documentation for Vybrid OCOTP driver
> 
>  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  21 ++
>  arch/arm/boot/dts/vfxxx.dtsi   |   9 +
>  drivers/clk/imx/clk-vf610.c|   1 +
>  drivers/nvmem/Kconfig  |  10 +
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/vf610-ocotp.c| 302 
> +
>  include/dt-bindings/clock/vf610-clock.h|   3 +-
>  7 files changed, 347 insertions(+), 1 deletion(-)
>  create mode 100644 

Re: [PATCH v9 0/4] Implement OCOTP driver for Vybrid using NVMEM

[maitysanchayan]

Hello,

Ping? Any feedback? Is this good to be merged?

Thanks.

- Sanchayan.

On 15-08-12 18:49:17, Sanchayan Maity wrote:
 Hello,
 
 This patchset is based on top of v9 of Srinivas's NVMEM framework patches.
 Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver
 patchset.
 
 Sample output on Colibri VF50
 
 root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a
 Linux colibri-vf 4.2.0-rc6-00130-g24fcfdc #3 SMP Wed Aug 12 18:31:24 IST 2015 
 armv7l GNU/Linux
 
 root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem
 000        
 *
 410 72a6 df64      
 420 11d4 2c14      
 430        
 *
 450 0280       
 460        
 *
 880 8f01       
 890        
 *
 8c0  1000      
 8d0 3202 0800      
 8e0  e100      
 8f0        
 *
 c80 bada bada      
 *
 cc0        
 *
 cf0
 
 The driver has changed quite a bit from the first version
 relying on of_platform_populate in mach file, to using
 SoC driver under drivers/soc and finally to NVMEM.
 
 Feedback and comments most welcome.
 
 Version 8 patches can be found here
 https://lkml.org/lkml/2015/8/10/566
 
 Version 7 patches can be found here
 https://lkml.org/lkml/2015/8/6/440
 
 Version 6 RFC patches can be found here
 http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html
 
 Version 5 of the patchset can be found here
 http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html
 
 Version 4 of the patchset can be found here
 https://lkml.org/lkml/2015/5/26/199
 
 Version 3 of the patchset can be found here
 http://www.spinics.net/lists/arm-kernel/msg420847.html
 
 Version 2 of the patchset can be found here
 http://www.spinics.net/lists/devicetree/msg80654.html
 
 Version 1 of the patchset can be found here
 http://www.spinics.net/lists/devicetree/msg80257.html
 
 The RFC version can be found here
 https://lkml.org/lkml/2015/5/11/13
 
 Changes since v8:
 1. Fix three lines over 80 characters
 2. Rebase on top of Greg's char-misc-next branch
 
 Changes since v7:
 1. Add COMPILE_TEST to Kconfig
 2. Use GENMASK and BIT macros where applicable
 3. Fix a code alignment issue
 4. Get the max_register value for regmap config using
 resource_size()
 5. Also add copyright info as the driver logic is based off
 on ocotp code in barebox
 6. Add missing info related to clock in DT binding doc
 
 Changes since v6:
 1. Use the v9 of NVMEM framework patchset
 2. Add a few comments
 3. Initialise buffer address not part of the fuse map to 0
 instead of only handling buffer locations with valid fuse
 addresses.
 
 Changes since v5:
 Use NVMEM framework by Srinivas and Maxime
 
 Changes since v4:
 1. Use devm_* family of functions and use a struct to get rid of
 global variables (suggested by Joachim Eastwood)
 2. Make Kconfig govern the compilation with tristate, instead of
 earlier bool. Paul Bolle raised a valid point that perhaps this
 should have been built in with the bool, however I had not taken
 into consideration generic distro kernels and it makes sense to
 have this tristated. (comments from Paul Bolle and Andreas Farber)
 
 Changes since v3:
 Instead of using the syscon_regmap_lookup_by_compatible function
 use a phandle in the device tree along with offsets specified in
 this phandle node and then read the offset along with the device
 node in the driver for reading from the required region.
 
 Changes since v2:
 Implement the SoC bus code as a driver in drivers/soc
 by registering with fsl,mscm-cpucfg as per Arnd's feedback
 
 Changes since v1:
 Sort the headers in alphabetical order
 
 Changes since RFC:
 Use a DT entry for the ROM area while specifying it as syscon.
 
 Thanks  Regards,
 Sanchayan Maity.
 
 Sanchayan Maity (4):
   clk: clk-vf610: Add clock for Vybrid OCOTP controller
   ARM: dts: vfxxx: Add OCOTP node
   drivers: nvmem: Add Vybrid OCOTP support
   nvmem: Add DT binding documentation for Vybrid OCOTP driver
 
  .../devicetree/bindings/nvmem/vf610-ocotp.txt  |  21 ++
  arch/arm/boot/dts/vfxxx.dtsi   |   9 +
  drivers/clk/imx/clk-vf610.c|   1 +
  drivers/nvmem/Kconfig  |  10 +
  drivers/nvmem/Makefile |   2 +
  drivers/nvmem/vf610-ocotp.c| 302 
 +
  include/dt-bindings/clock/vf610-clock.h|   3 +-
  7 files changed, 347 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
  create mode 100644 drivers/nvmem/vf610-ocotp.c
 
 -- 
 2.5.0
 
--
To unsubscribe 

Re: [PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[maitysanchayan]

Hello Dmitry,

On 15-08-21 18:30:57, Dmitry Torokhov wrote:
> Hi Sanchayan,
> 
> On Fri, Aug 21, 2015 at 06:56:32PM +0530, Sanchayan Maity wrote:
> > The Colibri Vybrid VF50 module supports 4-wire touchscreens using
> > FETs and ADC inputs. This driver uses the IIO consumer interface
> > and relies on the vf610_adc driver based on the IIO framework.
> > 
> 
> Thank you for making changes. I have a few comments still.

It has really improved with your comments. Thanks for your feedback.

> 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/input/touchscreen/Kconfig   |  12 +
> >  drivers/input/touchscreen/Makefile  |   1 +
> >  drivers/input/touchscreen/colibri-vf50-ts.c | 370 
> > 
> >  3 files changed, 383 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 80f6386..28948ca 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
> >   To compile this driver as a module, choose M here: the
> >   module will be called zforce_ts.
> >  
> > +config TOUCHSCREEN_COLIBRI_VF50
> > +   tristate "Toradex Colibri on board touchscreen driver"
> > +   depends on GPIOLIB && IIO && VF610_ADC
> 
> Can we possibly add "|| COMPILE_TEST" dependency? Will it compile
> without IIO or VF610_ADC enabled?

I will add and do the checks. It should compile without VF610_ADC
atleast, I don't see how it will without the others. I will check
once at my end also with other configs.

> 
> 
> > +   help
> > + Say Y here if you have a Colibri VF50 and plan to use
> > + the on-board provided 4-wire touchscreen driver.
> > +
> > + If unsure, say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called colibri_vf50_ts.
> > +
> >  endif
> > diff --git a/drivers/input/touchscreen/Makefile 
> > b/drivers/input/touchscreen/Makefile
> > index 44deea7..93746a0 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
> >  obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
> > +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
> > diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
> > b/drivers/input/touchscreen/colibri-vf50-ts.c
> > new file mode 100644
> > index 000..0793fdc
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
> > @@ -0,0 +1,370 @@
> > +/* Copyright 2015 Toradex AG
> > + *
> > + * Toradex Colibri VF50 Touchscreen driver
> > + *
> > + * Originally authored by Stefan Agner for 3.0 kernel
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Don't you need gpio/consumer.h?

Yes.

> 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "colibri-vf50-ts"
> > +#define DRV_VERSION "1.0"
> > +
> > +#define VF_ADC_MAX ((1 << 12) - 1)
> > +
> > +#define COLI_TOUCH_MIN_DELAY_US 1000
> > +#define COLI_TOUCH_MAX_DELAY_US 2000
> > +#define COLI_TOUCH_NO_OF_AVGS  5
> > +
> > +struct vf50_touch_device {
> > +   struct platform_device  *pdev;
> > +   struct input_dev*ts_input;
> > +   struct iio_channel  *channels;
> > +   struct gpio_desc *gpio_xp;
> > +   struct gpio_desc *gpio_xm;
> > +   struct gpio_desc *gpio_yp;
> > +   struct gpio_desc *gpio_ym;
> > +   struct gpio_desc *gpio_pen_detect;
> 
> I do not see gpio_pen_detect being used anymore.

Sorry. My mistake. It needs to be deleted. Will fix.

> 
> > +   int pen_irq;
> > +   int min_pressure;
> > +   bool stop_touchscreen;
> > +};
> > +
> > +/*
> > + * Enables given plates and measures touch parameters using ADC
> > + */
> > +static int adc_ts_measure(struct iio_channel *channel,
> > + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
> > +{
> > +   int i, value = 0, val = 0;
> > +   int ret;
> > +
> > +   gpiod_set_value(plate_p, 1);
> > +   gpiod_set_value(plate_m, 1);
> > +
> > +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
> > +
> > +   for (i = 0; i < COLI_TOUCH_NO_OF_AVGS; i++) {
> > +   ret = iio_read_channel_raw(channel, );
> > +   if (ret < 0) {
> > +   value = ret;
> > +   goto error_iio_read;
> > +   }
> > +
> > +   value += val;
> > +   }
> > +
> > + 

Re: [PATCH v4 2/3] input: Add DT binding documentation for Colibri VF50 touchscreen

[maitysanchayan]

On 15-08-22 18:36:54, Stefan Agner wrote:
> On 2015-08-21 06:26, Sanchayan Maity wrote:
> > This adds device tree binding documentation for the Colibri VF50
> > touchscreen driver.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/input/touchscreen/colibri-vf50-ts.txt | 36 
> > ++
> >  1 file changed, 36 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> > b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> > new file mode 100644
> > index 000..e615aa9
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> > @@ -0,0 +1,36 @@
> > +* Toradex Colibri VF50 Touchscreen driver
> > +
> > +Required Properties:
> > +- compatible must be toradex,vf50-touchscreen
> > +- io-channels: adc channels being used by the Colibri VF50 module
> > +- xp-gpios: FET gate driver for input of X+
> > +- xm-gpios: FET gate driver for input of X-
> > +- yp-gpios: FET gate driver for input of Y+
> > +- ym-gpios: FET gate driver for input of Y-
> > +- interrupt-parent: phandle for the interrupt controller
> > +- interrupts: pen irq interrupt for touch detection
> 
> I like the use of the interrupt interface for the touch detection pin.
> Maybe you can mention here that this is (typically) a GPIO...
> 
> > +- pinctrl-names: "idle", "default", "gpios"
> > +- pinctrl-0: pinctrl node for idle state gpio pinmux
> > +- pinctrl-1: pinctrl node for touch detection state pinmux
> 
> "touch detection" for default is rather confusing or even wrong. The
> Idle state is used for pen/touch detection, default is used for X/Y and
> Pressure measurement (maybe better described as touch measurement).

Ok. Understood. I see how my wordings can create confusion or are
misleading. Will fix.

- Sanchayan.

> 
> > +- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
> > +- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y 
> > values
> > +
> > +Example:
> > +
> > +   touchctrl: vf50_touchctrl {
> > +   compatible = "toradex,vf50-touchscreen";
> > +   io-channels = < 0>,< 0>,
> > +   < 1>,< 2>;
> > +   xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> > +   xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> > +   yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> > +   ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> > +   interrupt-parent = <>;
> > +   interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> > +   pinctrl-names = "idle","default","gpios";
> > +   pinctrl-0 = <_touchctrl_idle>;
> > +   pinctrl-1 = <_touchctrl_default>;
> > +   pinctrl-2 = <_touchctrl_gpios>;
> > +   vf50-ts-min-pressure = <200>;
> > +   status = "disabled";
> > +   };
> 
> Otherwise I agree with 1 and 2:
> 
> Acked-by: Stefan Agner 
> 
> --
> Stefan
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[maitysanchayan]

On 15-08-22 18:52:28, Stefan Agner wrote:
> Hi Sanchayan,
> 
> On 2015-08-21 06:26, Sanchayan Maity wrote:
> > +static int vf50_ts_probe(struct platform_device *pdev)
> > +{
> > +   struct input_dev *input;
> > +   struct iio_channel *channels;
> > +   struct device *dev = >dev;
> > +   struct vf50_touch_device *touchdev;
> > +   int error;
> > +
> > +   channels = iio_channel_get_all(dev);
> > +   if (IS_ERR(channels))
> > +   return PTR_ERR(channels);
> 
> Hm, we expect here that four channels are returned, however a faulty
> device tree could contain less. Access to the fourth channel above would
> lead to a bug.
> 
> Can you check the amount of channels returned? The returned list is
> explicitly terminated with a null entry, you can rely on that. Something
> similar to hwmon should do the job.
> http://lxr.free-electrons.com/source/drivers/hwmon/iio_hwmon.c#L86

I agree. It did be nice to have this error check. Thanks. I will add
this check so we can bail out if less channels are specified.

- Sanchayan.

> 
> 
> Otherwise, Acked-by: Stefan Agner 
> 
> --
> Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[maitysanchayan]

On 15-08-22 18:54:28, Stefan Agner wrote:
> On 2015-08-21 06:26, Sanchayan Maity wrote:
> > Add device tree node for touchscreen support on Colibri VF50. The
> > touchscreen functionality on VF50 uses the ADC channels of Vybrid
> > and some GPIOs. Also add pinctrl nodes for proper pinmux.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  4 +++
> >  arch/arm/boot/dts/vf500-colibri.dtsi| 47 
> > +
> >  2 files changed, 51 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> > b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> > index 7fc782c..14c0b00 100644
> > --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> > +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> > @@ -15,3 +15,7 @@
> > model = "Toradex Colibri VF50 on Colibri Evaluation Board";
> > compatible = "toradex,vf500-colibri_vf50-on-eval",
> > "toradex,vf500-colibri_vf50", "fsl,vf500";
> >  };
> > +
> > + {
> > +   status = "okay";
> > +};
> > diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
> > b/arch/arm/boot/dts/vf500-colibri.dtsi
> > index cee34a3..84f091d 100644
> > --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> > +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> > @@ -17,4 +17,51 @@
> > memory {
> > reg = <0x8000 0x800>;
> > };
> > +
> > +   touchscreen: vf50-touchscreen {
> > +   compatible = "toradex,vf50-touchscreen";
> > +   io-channels = < 0>,< 0>,
> > +   < 1>,< 2>;
> > +   xp-gpios = < 13 GPIO_ACTIVE_LOW>;
> > +   xm-gpios = < 29 GPIO_ACTIVE_HIGH>;
> > +   yp-gpios = < 12 GPIO_ACTIVE_LOW>;
> > +   ym-gpios = < 4 GPIO_ACTIVE_HIGH>;
> > +   interrupt-parent = <>;
> > +   interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> > +   pinctrl-names = "idle","default","gpios";
> > +   pinctrl-0 = <_touchctrl_idle>;
> > +   pinctrl-1 = <_touchctrl_default>;
> > +   pinctrl-2 = <_touchctrl_gpios>;
> > +   vf50-ts-min-pressure = <200>;
> 
> Since this is a touch screen related property, we even would want to
> have that in the board specific device-tree (vf500-colibri-eval-v3.dts).

So the same property specified again in vf500-colibri-eval-v3.dts? Ok will
include the same.

- Sanchayan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/3] input: Add DT binding documentation for Colibri VF50 touchscreen

[maitysanchayan]

On 15-08-22 18:36:54, Stefan Agner wrote:
 On 2015-08-21 06:26, Sanchayan Maity wrote:
  This adds device tree binding documentation for the Colibri VF50
  touchscreen driver.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   .../bindings/input/touchscreen/colibri-vf50-ts.txt | 36 
  ++
   1 file changed, 36 insertions(+)
   create mode 100644
  Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  
  diff --git
  a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  new file mode 100644
  index 000..e615aa9
  --- /dev/null
  +++ 
  b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  @@ -0,0 +1,36 @@
  +* Toradex Colibri VF50 Touchscreen driver
  +
  +Required Properties:
  +- compatible must be toradex,vf50-touchscreen
  +- io-channels: adc channels being used by the Colibri VF50 module
  +- xp-gpios: FET gate driver for input of X+
  +- xm-gpios: FET gate driver for input of X-
  +- yp-gpios: FET gate driver for input of Y+
  +- ym-gpios: FET gate driver for input of Y-
  +- interrupt-parent: phandle for the interrupt controller
  +- interrupts: pen irq interrupt for touch detection
 
 I like the use of the interrupt interface for the touch detection pin.
 Maybe you can mention here that this is (typically) a GPIO...
 
  +- pinctrl-names: idle, default, gpios
  +- pinctrl-0: pinctrl node for idle state gpio pinmux
  +- pinctrl-1: pinctrl node for touch detection state pinmux
 
 touch detection for default is rather confusing or even wrong. The
 Idle state is used for pen/touch detection, default is used for X/Y and
 Pressure measurement (maybe better described as touch measurement).

Ok. Understood. I see how my wordings can create confusion or are
misleading. Will fix.

- Sanchayan.

 
  +- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
  +- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y 
  values
  +
  +Example:
  +
  +   touchctrl: vf50_touchctrl {
  +   compatible = toradex,vf50-touchscreen;
  +   io-channels = adc1 0,adc0 0,
  +   adc0 1,adc1 2;
  +   xp-gpios = gpio0 13 GPIO_ACTIVE_LOW;
  +   xm-gpios = gpio2 29 GPIO_ACTIVE_HIGH;
  +   yp-gpios = gpio0 12 GPIO_ACTIVE_LOW;
  +   ym-gpios = gpio0 4 GPIO_ACTIVE_HIGH;
  +   interrupt-parent = gpio0;
  +   interrupts = 8 IRQ_TYPE_LEVEL_LOW;
  +   pinctrl-names = idle,default,gpios;
  +   pinctrl-0 = pinctrl_touchctrl_idle;
  +   pinctrl-1 = pinctrl_touchctrl_default;
  +   pinctrl-2 = pinctrl_touchctrl_gpios;
  +   vf50-ts-min-pressure = 200;
  +   status = disabled;
  +   };
 
 Otherwise I agree with 1 and 2:
 
 Acked-by: Stefan Agner ste...@agner.ch
 
 --
 Stefan
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[maitysanchayan]

On 15-08-22 18:54:28, Stefan Agner wrote:
 On 2015-08-21 06:26, Sanchayan Maity wrote:
  Add device tree node for touchscreen support on Colibri VF50. The
  touchscreen functionality on VF50 uses the ADC channels of Vybrid
  and some GPIOs. Also add pinctrl nodes for proper pinmux.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  4 +++
   arch/arm/boot/dts/vf500-colibri.dtsi| 47 
  +
   2 files changed, 51 insertions(+)
  
  diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  index 7fc782c..14c0b00 100644
  --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
  @@ -15,3 +15,7 @@
  model = Toradex Colibri VF50 on Colibri Evaluation Board;
  compatible = toradex,vf500-colibri_vf50-on-eval,
  toradex,vf500-colibri_vf50, fsl,vf500;
   };
  +
  +touchscreen {
  +   status = okay;
  +};
  diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
  b/arch/arm/boot/dts/vf500-colibri.dtsi
  index cee34a3..84f091d 100644
  --- a/arch/arm/boot/dts/vf500-colibri.dtsi
  +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
  @@ -17,4 +17,51 @@
  memory {
  reg = 0x8000 0x800;
  };
  +
  +   touchscreen: vf50-touchscreen {
  +   compatible = toradex,vf50-touchscreen;
  +   io-channels = adc1 0,adc0 0,
  +   adc0 1,adc1 2;
  +   xp-gpios = gpio0 13 GPIO_ACTIVE_LOW;
  +   xm-gpios = gpio2 29 GPIO_ACTIVE_HIGH;
  +   yp-gpios = gpio0 12 GPIO_ACTIVE_LOW;
  +   ym-gpios = gpio0 4 GPIO_ACTIVE_HIGH;
  +   interrupt-parent = gpio0;
  +   interrupts = 8 IRQ_TYPE_LEVEL_LOW;
  +   pinctrl-names = idle,default,gpios;
  +   pinctrl-0 = pinctrl_touchctrl_idle;
  +   pinctrl-1 = pinctrl_touchctrl_default;
  +   pinctrl-2 = pinctrl_touchctrl_gpios;
  +   vf50-ts-min-pressure = 200;
 
 Since this is a touch screen related property, we even would want to
 have that in the board specific device-tree (vf500-colibri-eval-v3.dts).

So the same property specified again in vf500-colibri-eval-v3.dts? Ok will
include the same.

- Sanchayan.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[maitysanchayan]

On 15-08-22 18:52:28, Stefan Agner wrote:
 Hi Sanchayan,
 
 On 2015-08-21 06:26, Sanchayan Maity wrote:
  +static int vf50_ts_probe(struct platform_device *pdev)
  +{
  +   struct input_dev *input;
  +   struct iio_channel *channels;
  +   struct device *dev = pdev-dev;
  +   struct vf50_touch_device *touchdev;
  +   int error;
  +
  +   channels = iio_channel_get_all(dev);
  +   if (IS_ERR(channels))
  +   return PTR_ERR(channels);
 
 Hm, we expect here that four channels are returned, however a faulty
 device tree could contain less. Access to the fourth channel above would
 lead to a bug.
 
 Can you check the amount of channels returned? The returned list is
 explicitly terminated with a null entry, you can rely on that. Something
 similar to hwmon should do the job.
 http://lxr.free-electrons.com/source/drivers/hwmon/iio_hwmon.c#L86

I agree. It did be nice to have this error check. Thanks. I will add
this check so we can bail out if less channels are specified.

- Sanchayan.

 
 
 Otherwise, Acked-by: Stefan Agner ste...@agner.ch
 
 --
 Stefan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[maitysanchayan]

Hello Dmitry,

On 15-08-21 18:30:57, Dmitry Torokhov wrote:
 Hi Sanchayan,
 
 On Fri, Aug 21, 2015 at 06:56:32PM +0530, Sanchayan Maity wrote:
  The Colibri Vybrid VF50 module supports 4-wire touchscreens using
  FETs and ADC inputs. This driver uses the IIO consumer interface
  and relies on the vf610_adc driver based on the IIO framework.
  
 
 Thank you for making changes. I have a few comments still.

It has really improved with your comments. Thanks for your feedback.

 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/input/touchscreen/Kconfig   |  12 +
   drivers/input/touchscreen/Makefile  |   1 +
   drivers/input/touchscreen/colibri-vf50-ts.c | 370 
  
   3 files changed, 383 insertions(+)
   create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
  
  diff --git a/drivers/input/touchscreen/Kconfig 
  b/drivers/input/touchscreen/Kconfig
  index 80f6386..28948ca 100644
  --- a/drivers/input/touchscreen/Kconfig
  +++ b/drivers/input/touchscreen/Kconfig
  @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
To compile this driver as a module, choose M here: the
module will be called zforce_ts.
   
  +config TOUCHSCREEN_COLIBRI_VF50
  +   tristate Toradex Colibri on board touchscreen driver
  +   depends on GPIOLIB  IIO  VF610_ADC
 
 Can we possibly add || COMPILE_TEST dependency? Will it compile
 without IIO or VF610_ADC enabled?

I will add and do the checks. It should compile without VF610_ADC
atleast, I don't see how it will without the others. I will check
once at my end also with other configs.

 
 
  +   help
  + Say Y here if you have a Colibri VF50 and plan to use
  + the on-board provided 4-wire touchscreen driver.
  +
  + If unsure, say N.
  +
  + To compile this driver as a module, choose M here: the
  + module will be called colibri_vf50_ts.
  +
   endif
  diff --git a/drivers/input/touchscreen/Makefile 
  b/drivers/input/touchscreen/Makefile
  index 44deea7..93746a0 100644
  --- a/drivers/input/touchscreen/Makefile
  +++ b/drivers/input/touchscreen/Makefile
  @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
   obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
   obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
   obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
  +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
  diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
  b/drivers/input/touchscreen/colibri-vf50-ts.c
  new file mode 100644
  index 000..0793fdc
  --- /dev/null
  +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
  @@ -0,0 +1,370 @@
  +/* Copyright 2015 Toradex AG
  + *
  + * Toradex Colibri VF50 Touchscreen driver
  + *
  + * Originally authored by Stefan Agner for 3.0 kernel
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License as published by
  + * the Free Software Foundation; either version 2 of the License, or
  + * (at your option) any later version.
  + */
  +
  +#include linux/delay.h
  +#include linux/err.h
  +#include linux/gpio.h
  +#include linux/iio/consumer.h
  +#include linux/iio/types.h
  +#include linux/input.h
  +#include linux/interrupt.h
  +#include linux/kernel.h
  +#include linux/module.h
  +#include linux/pinctrl/consumer.h
 
 Don't you need gpio/consumer.h?

Yes.

 
  +#include linux/platform_device.h
  +#include linux/slab.h
  +#include linux/types.h
  +
  +#define DRIVER_NAME colibri-vf50-ts
  +#define DRV_VERSION 1.0
  +
  +#define VF_ADC_MAX ((1  12) - 1)
  +
  +#define COLI_TOUCH_MIN_DELAY_US 1000
  +#define COLI_TOUCH_MAX_DELAY_US 2000
  +#define COLI_TOUCH_NO_OF_AVGS  5
  +
  +struct vf50_touch_device {
  +   struct platform_device  *pdev;
  +   struct input_dev*ts_input;
  +   struct iio_channel  *channels;
  +   struct gpio_desc *gpio_xp;
  +   struct gpio_desc *gpio_xm;
  +   struct gpio_desc *gpio_yp;
  +   struct gpio_desc *gpio_ym;
  +   struct gpio_desc *gpio_pen_detect;
 
 I do not see gpio_pen_detect being used anymore.

Sorry. My mistake. It needs to be deleted. Will fix.

 
  +   int pen_irq;
  +   int min_pressure;
  +   bool stop_touchscreen;
  +};
  +
  +/*
  + * Enables given plates and measures touch parameters using ADC
  + */
  +static int adc_ts_measure(struct iio_channel *channel,
  + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
  +{
  +   int i, value = 0, val = 0;
  +   int ret;
  +
  +   gpiod_set_value(plate_p, 1);
  +   gpiod_set_value(plate_m, 1);
  +
  +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
  +
  +   for (i = 0; i  COLI_TOUCH_NO_OF_AVGS; i++) {
  +   ret = iio_read_channel_raw(channel, val);
  +   if (ret  0) {
  +   value = ret;
  +   goto error_iio_read;
  +   }
  +
  +   value += val;
  +   }
  +
  +   value /= COLI_TOUCH_NO_OF_AVGS;
  +
  

Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

[maitysanchayan]

Ping?

- Sanchayan.

On 15-08-06 21:28:22, Sanchayan Maity wrote:
> Add iio_hwmon node to expose the temperature channel on Vybrid
> as hardware monitor device using the iio_hwmon driver.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 39173bb..0993d66 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -597,5 +597,10 @@
>   status = "disabled";
>   };
>   };
> +
> + iio_hwmon {
> + compatible = "iio-hwmon";
> + io-channels = < 16>;
> + };
>   };
>  };
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

[maitysanchayan]

Ping?

- Sanchayan.

On 15-08-06 21:28:22, Sanchayan Maity wrote:
 Add iio_hwmon node to expose the temperature channel on Vybrid
 as hardware monitor device using the iio_hwmon driver.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 ---
  arch/arm/boot/dts/vfxxx.dtsi | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
 index 39173bb..0993d66 100644
 --- a/arch/arm/boot/dts/vfxxx.dtsi
 +++ b/arch/arm/boot/dts/vfxxx.dtsi
 @@ -597,5 +597,10 @@
   status = disabled;
   };
   };
 +
 + iio_hwmon {
 + compatible = iio-hwmon;
 + io-channels = adc0 16;
 + };
   };
  };
 -- 
 2.5.0
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

[maitysanchayan]

Hello Fugang Duan,

Can I have your ACK if you are ok with the changes made by the
patch?

Thanks & Regards,
Sanchayan Maity.

On 15-08-17 21:21:40, Sanchayan Maity wrote:
> This patch adds support for IIO buffer to the Vybrid ADC driver.
> IIO triggered buffer infrastructure along with iio sysfs trigger
> is used to leverage continuous sampling support provided by the
> ADC block.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> 
> Changes since v3:
> Fix iio_buffer_setup_ops for postenable and predisable functions
> to match pairwise. Before this the predisable work was being done
> in postdisable.
> 
> Changes since v2:
> 1. Fix the wrong buffer size for statically allocated buffer
> 2. Drop the use of .address field from the iio_chan_spec
> 3. Use iio_buffer_enabled call inside the lock
> 4. Drop wrapper function around iio_trigered_* function calls
> 5. Drop Kconfig select of sysfs trigger
> 6. Drop Kconfig select IIO_TRIGGER as it is already selected by
> IIO_TRIGGERED_BUFFER
> 
> Changes since v1:
> 1. Use a fixed size buffer instead of kmalloc allocated during update
> scan mode
> 2. Remove a write to read only register ADC_HS (COCO bit)
> 
>  drivers/iio/adc/Kconfig |   2 +
>  drivers/iio/adc/vf610_adc.c | 105 
> +---
>  2 files changed, 100 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7c55658..660f790 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -337,6 +337,8 @@ config TWL6030_GPADC
>  config VF610_ADC
>   tristate "Freescale vf610 ADC driver"
>   depends on OF
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
>   help
> Say yes here to support for Vybrid board analog-to-digital converter.
> Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
> diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> index 23b8fb9..887a7ba 100644
> --- a/drivers/iio/adc/vf610_adc.c
> +++ b/drivers/iio/adc/vf610_adc.c
> @@ -34,8 +34,11 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
> -#include 
> +#include 
> +#include 
> +#include 
>  
>  /* This will be the driver name the kernel reports */
>  #define DRIVER_NAME "vf610-adc"
> @@ -170,6 +173,7 @@ struct vf610_adc {
>   u32 sample_freq_avail[5];
>  
>   struct completion completion;
> + u16 buffer[8];
>  };
>  
>  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
> @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
> vf610_ext_info[] = {
>   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
>   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
>   .ext_info = vf610_ext_info, \
> + .scan_index = (_idx),   \
> + .scan_type = {  \
> + .sign = 'u',\
> + .realbits = 12, \
> + .storagebits = 16,  \
> + },  \
>  }
>  
>  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) {   \
>   .type = (_chan_type),   \
>   .channel = (_idx),  \
>   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> + .scan_index = (_idx),   \
> + .scan_type = {  \
> + .sign = 'u',\
> + .realbits = 12, \
> + .storagebits = 16,  \
> + },  \
>  }
>  
>  static const struct iio_chan_spec vf610_adc_iio_channels[] = {
> @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
> vf610_adc_iio_channels[] = {
>   VF610_ADC_CHAN(14, IIO_VOLTAGE),
>   VF610_ADC_CHAN(15, IIO_VOLTAGE),
>   VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
> + IIO_CHAN_SOFT_TIMESTAMP(32),
>   /* sentinel */
>  };
>  
> @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
>  
>  static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
>  {
> - struct vf610_adc *info = (struct vf610_adc *)dev_id;
> + struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
> + struct vf610_adc *info = iio_priv(indio_dev);
>   int coco;
>  
>   coco = readl(info->regs + VF610_REG_ADC_HS);
>   if (coco & VF610_ADC_HS_COCO0) {
>   info->value = vf610_adc_read_data(info);
> - complete(>completion);
> + if (iio_buffer_enabled(indio_dev)) {
> + info->buffer[0] = info->value;
> + iio_push_to_buffers_with_timestamp(indio_dev,
> + info->buffer, iio_get_time_ns());
> + iio_trigger_notify_done(indio_dev->trig);
> + } else
> + 

Re: [PATCH v4] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

[maitysanchayan]

Hello Fugang Duan,

Can I have your ACK if you are ok with the changes made by the
patch?

Thanks  Regards,
Sanchayan Maity.

On 15-08-17 21:21:40, Sanchayan Maity wrote:
 This patch adds support for IIO buffer to the Vybrid ADC driver.
 IIO triggered buffer infrastructure along with iio sysfs trigger
 is used to leverage continuous sampling support provided by the
 ADC block.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 ---
 
 Changes since v3:
 Fix iio_buffer_setup_ops for postenable and predisable functions
 to match pairwise. Before this the predisable work was being done
 in postdisable.
 
 Changes since v2:
 1. Fix the wrong buffer size for statically allocated buffer
 2. Drop the use of .address field from the iio_chan_spec
 3. Use iio_buffer_enabled call inside the lock
 4. Drop wrapper function around iio_trigered_* function calls
 5. Drop Kconfig select of sysfs trigger
 6. Drop Kconfig select IIO_TRIGGER as it is already selected by
 IIO_TRIGGERED_BUFFER
 
 Changes since v1:
 1. Use a fixed size buffer instead of kmalloc allocated during update
 scan mode
 2. Remove a write to read only register ADC_HS (COCO bit)
 
  drivers/iio/adc/Kconfig |   2 +
  drivers/iio/adc/vf610_adc.c | 105 
 +---
  2 files changed, 100 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
 index 7c55658..660f790 100644
 --- a/drivers/iio/adc/Kconfig
 +++ b/drivers/iio/adc/Kconfig
 @@ -337,6 +337,8 @@ config TWL6030_GPADC
  config VF610_ADC
   tristate Freescale vf610 ADC driver
   depends on OF
 + select IIO_BUFFER
 + select IIO_TRIGGERED_BUFFER
   help
 Say yes here to support for Vybrid board analog-to-digital converter.
 Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
 diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
 index 23b8fb9..887a7ba 100644
 --- a/drivers/iio/adc/vf610_adc.c
 +++ b/drivers/iio/adc/vf610_adc.c
 @@ -34,8 +34,11 @@
  #include linux/err.h
  
  #include linux/iio/iio.h
 +#include linux/iio/buffer.h
  #include linux/iio/sysfs.h
 -#include linux/iio/driver.h
 +#include linux/iio/trigger.h
 +#include linux/iio/trigger_consumer.h
 +#include linux/iio/triggered_buffer.h
  
  /* This will be the driver name the kernel reports */
  #define DRIVER_NAME vf610-adc
 @@ -170,6 +173,7 @@ struct vf610_adc {
   u32 sample_freq_avail[5];
  
   struct completion completion;
 + u16 buffer[8];
  };
  
  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
 @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
 vf610_ext_info[] = {
   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
   .ext_info = vf610_ext_info, \
 + .scan_index = (_idx),   \
 + .scan_type = {  \
 + .sign = 'u',\
 + .realbits = 12, \
 + .storagebits = 16,  \
 + },  \
  }
  
  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) {   \
   .type = (_chan_type),   \
   .channel = (_idx),  \
   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
 + .scan_index = (_idx),   \
 + .scan_type = {  \
 + .sign = 'u',\
 + .realbits = 12, \
 + .storagebits = 16,  \
 + },  \
  }
  
  static const struct iio_chan_spec vf610_adc_iio_channels[] = {
 @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
 vf610_adc_iio_channels[] = {
   VF610_ADC_CHAN(14, IIO_VOLTAGE),
   VF610_ADC_CHAN(15, IIO_VOLTAGE),
   VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
 + IIO_CHAN_SOFT_TIMESTAMP(32),
   /* sentinel */
  };
  
 @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
  
  static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
  {
 - struct vf610_adc *info = (struct vf610_adc *)dev_id;
 + struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
 + struct vf610_adc *info = iio_priv(indio_dev);
   int coco;
  
   coco = readl(info-regs + VF610_REG_ADC_HS);
   if (coco  VF610_ADC_HS_COCO0) {
   info-value = vf610_adc_read_data(info);
 - complete(info-completion);
 + if (iio_buffer_enabled(indio_dev)) {
 + info-buffer[0] = info-value;
 + iio_push_to_buffers_with_timestamp(indio_dev,
 + info-buffer, iio_get_time_ns());
 + iio_trigger_notify_done(indio_dev-trig);
 +

Re: [PATCH v3 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[maitysanchayan]

Hello Dmitry,

Will take care of all points with the next revision.

Thank you for the feedback.

- Sanchayan.

On 15-08-14 15:53:46, Dmitry Torokhov wrote:
> Hi Sanchayan,
> 
> On Wed, Aug 05, 2015 at 02:25:51PM +0530, Sanchayan Maity wrote:
> > The Colibri Vybrid VF50 module supports 4-wire touchscreens using
> > FETs and ADC inputs. This driver uses the IIO consumer interface
> > and relies on the vf610_adc driver based on the IIO framework.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  drivers/input/touchscreen/Kconfig   |  12 +
> >  drivers/input/touchscreen/Makefile  |   1 +
> >  drivers/input/touchscreen/colibri-vf50-ts.c | 404 
> > 
> >  3 files changed, 417 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 80f6386..28948ca 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
> >   To compile this driver as a module, choose M here: the
> >   module will be called zforce_ts.
> >  
> > +config TOUCHSCREEN_COLIBRI_VF50
> > +   tristate "Toradex Colibri on board touchscreen driver"
> > +   depends on GPIOLIB && IIO && VF610_ADC
> > +   help
> > + Say Y here if you have a Colibri VF50 and plan to use
> > + the on-board provided 4-wire touchscreen driver.
> > +
> > + If unsure, say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called colibri_vf50_ts.
> > +
> >  endif
> > diff --git a/drivers/input/touchscreen/Makefile 
> > b/drivers/input/touchscreen/Makefile
> > index 44deea7..93746a0 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
> >  obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
> > +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
> > diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
> > b/drivers/input/touchscreen/colibri-vf50-ts.c
> > new file mode 100644
> > index 000..d7bc91a
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
> > @@ -0,0 +1,404 @@
> > +/* Copyright 2015 Toradex AG
> > + *
> > + * Toradex Colibri VF50 Touchscreen driver
> > + *
> > + * Originally authored by Stefan Agner for 3.0 kernel
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "colibri-vf50-ts"
> > +#define DRV_VERSION "1.0"
> > +
> > +#define VF_ADC_MAX ((1 << 12) - 1)
> > +
> > +#define COLI_TOUCH_MIN_DELAY_US 1000
> > +#define COLI_TOUCH_MAX_DELAY_US 2000
> > +
> > +static int min_pressure = 200;
> > +
> > +struct vf50_touch_device {
> > +   struct platform_device  *pdev;
> > +   struct input_dev*ts_input;
> > +   struct iio_channel  *channels;
> > +   struct gpio_desc *gpio_xp;
> > +   struct gpio_desc *gpio_xm;
> > +   struct gpio_desc *gpio_yp;
> > +   struct gpio_desc *gpio_ym;
> > +   struct gpio_desc *gpio_pen_detect;
> > +   int pen_irq;
> > +   bool stop_touchscreen;
> > +};
> > +
> > +/*
> > + * Enables given plates and measures touch parameters using ADC
> > + */
> > +static int adc_ts_measure(struct iio_channel *channel,
> > + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
> > +{
> > +   int i, value = 0, val = 0;
> > +   int ret;
> > +
> > +   gpiod_set_value(plate_p, 1);
> > +   gpiod_set_value(plate_m, 1);
> > +
> > +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
> > +
> > +   for (i = 0; i < 5; i++) {
> 
> Can we have a #define for 5?
> 
> > +   ret = iio_read_channel_raw(channel, );
> > +   if (ret < 0) {
> > +   value = ret;
> > +   goto error_iio_read;
> > +   }
> > +
> > +   value += val;
> > +   }
> > +
> > +   value /= 5;
> > +
> > +error_iio_read:
> > +   gpiod_set_value(plate_p, 0);
> > +   gpiod_set_value(plate_m, 0);
> > +
> > +   return value;
> > +}
> > +
> > +/*
> > + * Enable touch detection using falling edge detection on XM
> > + */
> > +static void vf50_ts_enable_touch_detection(struct vf50_touch_device 
> > *vf50_ts)
> > +{
> > +   /* Enable plate YM (needs to be strong GND, high active) */
> > +   gpiod_set_value(vf50_ts->gpio_ym, 1);
> > +
> > +   /*
> > +* Let the platform 

Re: [PATCH v3 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[maitysanchayan]

Hello Dmitry,

Will take care of all points with the next revision.

Thank you for the feedback.

- Sanchayan.

On 15-08-14 15:53:46, Dmitry Torokhov wrote:
 Hi Sanchayan,
 
 On Wed, Aug 05, 2015 at 02:25:51PM +0530, Sanchayan Maity wrote:
  The Colibri Vybrid VF50 module supports 4-wire touchscreens using
  FETs and ADC inputs. This driver uses the IIO consumer interface
  and relies on the vf610_adc driver based on the IIO framework.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   drivers/input/touchscreen/Kconfig   |  12 +
   drivers/input/touchscreen/Makefile  |   1 +
   drivers/input/touchscreen/colibri-vf50-ts.c | 404 
  
   3 files changed, 417 insertions(+)
   create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
  
  diff --git a/drivers/input/touchscreen/Kconfig 
  b/drivers/input/touchscreen/Kconfig
  index 80f6386..28948ca 100644
  --- a/drivers/input/touchscreen/Kconfig
  +++ b/drivers/input/touchscreen/Kconfig
  @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
To compile this driver as a module, choose M here: the
module will be called zforce_ts.
   
  +config TOUCHSCREEN_COLIBRI_VF50
  +   tristate Toradex Colibri on board touchscreen driver
  +   depends on GPIOLIB  IIO  VF610_ADC
  +   help
  + Say Y here if you have a Colibri VF50 and plan to use
  + the on-board provided 4-wire touchscreen driver.
  +
  + If unsure, say N.
  +
  + To compile this driver as a module, choose M here: the
  + module will be called colibri_vf50_ts.
  +
   endif
  diff --git a/drivers/input/touchscreen/Makefile 
  b/drivers/input/touchscreen/Makefile
  index 44deea7..93746a0 100644
  --- a/drivers/input/touchscreen/Makefile
  +++ b/drivers/input/touchscreen/Makefile
  @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
   obj-$(CONFIG_TOUCHSCREEN_SX8654)   += sx8654.o
   obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
   obj-$(CONFIG_TOUCHSCREEN_ZFORCE)   += zforce_ts.o
  +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
  diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
  b/drivers/input/touchscreen/colibri-vf50-ts.c
  new file mode 100644
  index 000..d7bc91a
  --- /dev/null
  +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
  @@ -0,0 +1,404 @@
  +/* Copyright 2015 Toradex AG
  + *
  + * Toradex Colibri VF50 Touchscreen driver
  + *
  + * Originally authored by Stefan Agner for 3.0 kernel
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License as published by
  + * the Free Software Foundation; either version 2 of the License, or
  + * (at your option) any later version.
  + */
  +
  +#include linux/delay.h
  +#include linux/err.h
  +#include linux/gpio.h
  +#include linux/iio/consumer.h
  +#include linux/iio/types.h
  +#include linux/input.h
  +#include linux/interrupt.h
  +#include linux/kernel.h
  +#include linux/module.h
  +#include linux/pinctrl/consumer.h
  +#include linux/platform_device.h
  +#include linux/slab.h
  +#include linux/types.h
  +
  +#define DRIVER_NAME colibri-vf50-ts
  +#define DRV_VERSION 1.0
  +
  +#define VF_ADC_MAX ((1  12) - 1)
  +
  +#define COLI_TOUCH_MIN_DELAY_US 1000
  +#define COLI_TOUCH_MAX_DELAY_US 2000
  +
  +static int min_pressure = 200;
  +
  +struct vf50_touch_device {
  +   struct platform_device  *pdev;
  +   struct input_dev*ts_input;
  +   struct iio_channel  *channels;
  +   struct gpio_desc *gpio_xp;
  +   struct gpio_desc *gpio_xm;
  +   struct gpio_desc *gpio_yp;
  +   struct gpio_desc *gpio_ym;
  +   struct gpio_desc *gpio_pen_detect;
  +   int pen_irq;
  +   bool stop_touchscreen;
  +};
  +
  +/*
  + * Enables given plates and measures touch parameters using ADC
  + */
  +static int adc_ts_measure(struct iio_channel *channel,
  + struct gpio_desc *plate_p, struct gpio_desc *plate_m)
  +{
  +   int i, value = 0, val = 0;
  +   int ret;
  +
  +   gpiod_set_value(plate_p, 1);
  +   gpiod_set_value(plate_m, 1);
  +
  +   usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
  +
  +   for (i = 0; i  5; i++) {
 
 Can we have a #define for 5?
 
  +   ret = iio_read_channel_raw(channel, val);
  +   if (ret  0) {
  +   value = ret;
  +   goto error_iio_read;
  +   }
  +
  +   value += val;
  +   }
  +
  +   value /= 5;
  +
  +error_iio_read:
  +   gpiod_set_value(plate_p, 0);
  +   gpiod_set_value(plate_m, 0);
  +
  +   return value;
  +}
  +
  +/*
  + * Enable touch detection using falling edge detection on XM
  + */
  +static void vf50_ts_enable_touch_detection(struct vf50_touch_device 
  *vf50_ts)
  +{
  +   /* Enable plate YM (needs to be strong GND, high active) */
  +   gpiod_set_value(vf50_ts-gpio_ym, 1);
  +
  +   /*
  +* Let the platform mux to idle state in order to enable
  +* Pull-Up on GPIO
  +*/
  +   

Re: [PATCH v3] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

[maitysanchayan]

Hello Jonathan,

On 15-08-15 21:24:01, Jonathan Cameron wrote:
> On 11/08/15 10:05, Sanchayan Maity wrote:
> > This patch adds support for IIO buffer to the Vybrid ADC driver.
> > IIO triggered buffer infrastructure along with iio sysfs trigger
> > is used to leverage continuous sampling support provided by the
> > ADC block.
> > 
> > Signed-off-by: Sanchayan Maity 
> Hi Sanchayan,
> 
> Very nearly there. One little point to do with the buffer handling.
> Basically I don't think you want anything in the preenable or
> postdisable hooks, just in the 'internal' ones.
> 
> Jonathan
> > ---
> >  drivers/iio/adc/Kconfig |   2 +
> >  drivers/iio/adc/vf610_adc.c | 102 
> > +---
> >  2 files changed, 97 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 7c55658..660f790 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -337,6 +337,8 @@ config TWL6030_GPADC
> >  config VF610_ADC
> > tristate "Freescale vf610 ADC driver"
> > depends on OF
> > +   select IIO_BUFFER
> > +   select IIO_TRIGGERED_BUFFER
> > help
> >   Say yes here to support for Vybrid board analog-to-digital converter.
> >   Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
> > diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> > index 23b8fb9..de62c48 100644
> > --- a/drivers/iio/adc/vf610_adc.c
> > +++ b/drivers/iio/adc/vf610_adc.c
> > @@ -34,8 +34,11 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  /* This will be the driver name the kernel reports */
> >  #define DRIVER_NAME "vf610-adc"
> > @@ -170,6 +173,7 @@ struct vf610_adc {
> > u32 sample_freq_avail[5];
> >  
> > struct completion completion;
> > +   u16 buffer[8];
> >  };
> >  
> >  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
> > @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
> > vf610_ext_info[] = {
> > .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
> > BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
> > .ext_info = vf610_ext_info, \
> > +   .scan_index = (_idx),   \
> > +   .scan_type = {  \
> > +   .sign = 'u',\
> > +   .realbits = 12, \
> > +   .storagebits = 16,  \
> > +   },  \
> >  }
> >  
> >  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
> > .type = (_chan_type),   \
> > .channel = (_idx),  \
> > .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> > +   .scan_index = (_idx),   \
> > +   .scan_type = {  \
> > +   .sign = 'u',\
> > +   .realbits = 12, \
> > +   .storagebits = 16,  \
> > +   },  \
> >  }
> >  
> >  static const struct iio_chan_spec vf610_adc_iio_channels[] = {
> > @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
> > vf610_adc_iio_channels[] = {
> > VF610_ADC_CHAN(14, IIO_VOLTAGE),
> > VF610_ADC_CHAN(15, IIO_VOLTAGE),
> > VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
> > +   IIO_CHAN_SOFT_TIMESTAMP(32),
> > /* sentinel */
> >  };
> >  
> > @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
> >  
> >  static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
> >  {
> > -   struct vf610_adc *info = (struct vf610_adc *)dev_id;
> > +   struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
> > +   struct vf610_adc *info = iio_priv(indio_dev);
> > int coco;
> >  
> > coco = readl(info->regs + VF610_REG_ADC_HS);
> > if (coco & VF610_ADC_HS_COCO0) {
> > info->value = vf610_adc_read_data(info);
> > -   complete(>completion);
> > +   if (iio_buffer_enabled(indio_dev)) {
> > +   info->buffer[0] = info->value;
> > +   iio_push_to_buffers_with_timestamp(indio_dev,
> > +   info->buffer, iio_get_time_ns());
> > +   iio_trigger_notify_done(indio_dev->trig);
> > +   } else
> > +   complete(>completion);
> > }
> >  
> > return IRQ_HANDLED;
> > @@ -613,8 +637,12 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
> > case IIO_CHAN_INFO_RAW:
> > case IIO_CHAN_INFO_PROCESSED:
> > mutex_lock(_dev->mlock);
> > -   reinit_completion(>completion);
> > +   if (iio_buffer_enabled(indio_dev)) {
> > +   mutex_unlock(_dev->mlock);
> > +   return -EBUSY;
> > +   }
> >  
> > +  

Re: [PATCH v3] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

[maitysanchayan]

Hello Jonathan,

On 15-08-15 21:24:01, Jonathan Cameron wrote:
 On 11/08/15 10:05, Sanchayan Maity wrote:
  This patch adds support for IIO buffer to the Vybrid ADC driver.
  IIO triggered buffer infrastructure along with iio sysfs trigger
  is used to leverage continuous sampling support provided by the
  ADC block.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
 Hi Sanchayan,
 
 Very nearly there. One little point to do with the buffer handling.
 Basically I don't think you want anything in the preenable or
 postdisable hooks, just in the 'internal' ones.
 
 Jonathan
  ---
   drivers/iio/adc/Kconfig |   2 +
   drivers/iio/adc/vf610_adc.c | 102 
  +---
   2 files changed, 97 insertions(+), 7 deletions(-)
  
  diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
  index 7c55658..660f790 100644
  --- a/drivers/iio/adc/Kconfig
  +++ b/drivers/iio/adc/Kconfig
  @@ -337,6 +337,8 @@ config TWL6030_GPADC
   config VF610_ADC
  tristate Freescale vf610 ADC driver
  depends on OF
  +   select IIO_BUFFER
  +   select IIO_TRIGGERED_BUFFER
  help
Say yes here to support for Vybrid board analog-to-digital converter.
Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
  diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
  index 23b8fb9..de62c48 100644
  --- a/drivers/iio/adc/vf610_adc.c
  +++ b/drivers/iio/adc/vf610_adc.c
  @@ -34,8 +34,11 @@
   #include linux/err.h
   
   #include linux/iio/iio.h
  +#include linux/iio/buffer.h
   #include linux/iio/sysfs.h
  -#include linux/iio/driver.h
  +#include linux/iio/trigger.h
  +#include linux/iio/trigger_consumer.h
  +#include linux/iio/triggered_buffer.h
   
   /* This will be the driver name the kernel reports */
   #define DRIVER_NAME vf610-adc
  @@ -170,6 +173,7 @@ struct vf610_adc {
  u32 sample_freq_avail[5];
   
  struct completion completion;
  +   u16 buffer[8];
   };
   
   static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
  @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
  vf610_ext_info[] = {
  .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
  BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
  .ext_info = vf610_ext_info, \
  +   .scan_index = (_idx),   \
  +   .scan_type = {  \
  +   .sign = 'u',\
  +   .realbits = 12, \
  +   .storagebits = 16,  \
  +   },  \
   }
   
   #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) { \
  .type = (_chan_type),   \
  .channel = (_idx),  \
  .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
  +   .scan_index = (_idx),   \
  +   .scan_type = {  \
  +   .sign = 'u',\
  +   .realbits = 12, \
  +   .storagebits = 16,  \
  +   },  \
   }
   
   static const struct iio_chan_spec vf610_adc_iio_channels[] = {
  @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
  vf610_adc_iio_channels[] = {
  VF610_ADC_CHAN(14, IIO_VOLTAGE),
  VF610_ADC_CHAN(15, IIO_VOLTAGE),
  VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
  +   IIO_CHAN_SOFT_TIMESTAMP(32),
  /* sentinel */
   };
   
  @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
   
   static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
   {
  -   struct vf610_adc *info = (struct vf610_adc *)dev_id;
  +   struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
  +   struct vf610_adc *info = iio_priv(indio_dev);
  int coco;
   
  coco = readl(info-regs + VF610_REG_ADC_HS);
  if (coco  VF610_ADC_HS_COCO0) {
  info-value = vf610_adc_read_data(info);
  -   complete(info-completion);
  +   if (iio_buffer_enabled(indio_dev)) {
  +   info-buffer[0] = info-value;
  +   iio_push_to_buffers_with_timestamp(indio_dev,
  +   info-buffer, iio_get_time_ns());
  +   iio_trigger_notify_done(indio_dev-trig);
  +   } else
  +   complete(info-completion);
  }
   
  return IRQ_HANDLED;
  @@ -613,8 +637,12 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
  case IIO_CHAN_INFO_RAW:
  case IIO_CHAN_INFO_PROCESSED:
  mutex_lock(indio_dev-mlock);
  -   reinit_completion(info-completion);
  +   if (iio_buffer_enabled(indio_dev)) {
  +   mutex_unlock(indio_dev-mlock);
  +   return -EBUSY;
  +   }
   
  +   reinit_completion(info-completion);
  

Re: [PATCH v3 0/3] Add support for touchscreen on Colibri VF50

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 15-08-05 14:25:48, Sanchayan Maity wrote:
> Hello,
> 
> The patchset adds support for 4 wire touchscreen on Toradex Colibri
> VF50 modules. Patches are tested on top of shawn's for-next branch.
> 
> Changes since v2:
> 1. Fix pin multiplexing for pins in idle state. Configuration of the
> pen detect pull up viz. PTA19__GPIO_9 resulted in generation of pen
> irq's on a continuous basis.
> 2. Fix pinmux of the ADC pins as per the recommended pinmux in TRM.
> 3. Use a threaded irq handler instead of a irq handler plus workqueue
> approach.
> 4. Use a low level trigger with oneshot flag specifier instead of the
> previous falling edge triggered irq's. This coupled with the fix in
> point 1 fixes the previous continuous spurious irq generation bug.
> 5. Change/fix the TS measurement logic to account for the fact that
> iio_channel_read_raw might actually return an error. To be more
> specific use break instead of continue and take care to close the
> FET's in case of channel read error.
> 6. Drop the first patch "Add io-channel-cells property for ADC node"
> as it has already been applied.
> 7. Move the iio channel get call again at the start. Having it in
> the end resulted in crashes sometimes when iio was not probed and
> the ts device got probed and opened earlier.
> 
> Changes since v1:
> 1. Fix/drop comments
> 2. Use an inline function for multiple gpiod_get calls in probe
> 3. Remove the pull up in the pinmux specified in DT for touchctrl_gpios
> 4. Add the io-channel-cells property before status property.
> 5. Add GPIOLIB as dependency in the Kconfig file
> 
> Version 2 of the patchset can be found here
> https://www.mail-archive.com/linux-input@vger.kernel.org/msg18090.html
> 
> Version 1 of the patchset can be found here
> https://lkml.org/lkml/2015/6/30/103
> 
> Thank you very much for the feedback till now.
> 
> Regards,
> Sanchayan.
> 
> Sanchayan Maity (3):
>   ARM: dts: vf500-colibri: Add device tree node for touchscreen support
>   input: Add DT binding documentation for Colibri VF50 touchscreen
>   touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50
> 
>  .../bindings/input/touchscreen/colibri-vf50-ts.txt |  32 ++
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts|   4 +
>  arch/arm/boot/dts/vf500-colibri.dtsi   |  45 +++
>  drivers/input/touchscreen/Kconfig  |  12 +
>  drivers/input/touchscreen/Makefile |   1 +
>  drivers/input/touchscreen/colibri-vf50-ts.c| 404 
> +
>  6 files changed, 498 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
>  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
> 
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/3] Add support for touchscreen on Colibri VF50

[maitysanchayan]

Hello,

Ping?

- Sanchayan.

On 15-08-05 14:25:48, Sanchayan Maity wrote:
 Hello,
 
 The patchset adds support for 4 wire touchscreen on Toradex Colibri
 VF50 modules. Patches are tested on top of shawn's for-next branch.
 
 Changes since v2:
 1. Fix pin multiplexing for pins in idle state. Configuration of the
 pen detect pull up viz. PTA19__GPIO_9 resulted in generation of pen
 irq's on a continuous basis.
 2. Fix pinmux of the ADC pins as per the recommended pinmux in TRM.
 3. Use a threaded irq handler instead of a irq handler plus workqueue
 approach.
 4. Use a low level trigger with oneshot flag specifier instead of the
 previous falling edge triggered irq's. This coupled with the fix in
 point 1 fixes the previous continuous spurious irq generation bug.
 5. Change/fix the TS measurement logic to account for the fact that
 iio_channel_read_raw might actually return an error. To be more
 specific use break instead of continue and take care to close the
 FET's in case of channel read error.
 6. Drop the first patch Add io-channel-cells property for ADC node
 as it has already been applied.
 7. Move the iio channel get call again at the start. Having it in
 the end resulted in crashes sometimes when iio was not probed and
 the ts device got probed and opened earlier.
 
 Changes since v1:
 1. Fix/drop comments
 2. Use an inline function for multiple gpiod_get calls in probe
 3. Remove the pull up in the pinmux specified in DT for touchctrl_gpios
 4. Add the io-channel-cells property before status property.
 5. Add GPIOLIB as dependency in the Kconfig file
 
 Version 2 of the patchset can be found here
 https://www.mail-archive.com/linux-input@vger.kernel.org/msg18090.html
 
 Version 1 of the patchset can be found here
 https://lkml.org/lkml/2015/6/30/103
 
 Thank you very much for the feedback till now.
 
 Regards,
 Sanchayan.
 
 Sanchayan Maity (3):
   ARM: dts: vf500-colibri: Add device tree node for touchscreen support
   input: Add DT binding documentation for Colibri VF50 touchscreen
   touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50
 
  .../bindings/input/touchscreen/colibri-vf50-ts.txt |  32 ++
  arch/arm/boot/dts/vf500-colibri-eval-v3.dts|   4 +
  arch/arm/boot/dts/vf500-colibri.dtsi   |  45 +++
  drivers/input/touchscreen/Kconfig  |  12 +
  drivers/input/touchscreen/Makefile |   1 +
  drivers/input/touchscreen/colibri-vf50-ts.c| 404 
 +
  6 files changed, 498 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
 
 -- 
 2.5.0
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 3/4] drivers: nvmem: Add Vybrid OCOTP support

[maitysanchayan]

Hello,

On 15-08-12 11:41:55, Srinivas Kandagatla wrote:
> Hi Sanchayan,
> 
> Please run checkpatch before you send the patch next time.
> Look at Documentation/SubmittingPatches for more details.
> 
> WARNING: line over 80 characters
> #225: FILE: drivers/nvmem/vf610-ocotp.c:174:
> + ret = vf610_ocotp_wait_busy(ocotp->base + 
> OCOTP_CTRL_REG);
> 
> WARNING: line over 80 characters
> #237: FILE: drivers/nvmem/vf610-ocotp.c:186:
> + ret = vf610_ocotp_wait_busy(ocotp->base + 
> OCOTP_CTRL_REG);
> 
> WARNING: line over 80 characters
> #244: FILE: drivers/nvmem/vf610-ocotp.c:193:
> + writel(OCOTP_CTRL_ERROR, ocotp->base + 
> OCOTP_CTRL_CLR);
> 

I had. However splitting these lines seemed odd. Will split and fix.

> 
> On 10/08/15 15:11, Sanchayan Maity wrote:
> > The patch adds support for the On Chip One Time Programmable Peripheral
> > (OCOTP) on the Vybrid platform.
> >
> > Signed-off-by: Sanchayan Maity 
> > ---
> >   drivers/nvmem/Kconfig   |  10 ++
> >   drivers/nvmem/Makefile  |   2 +
> >   drivers/nvmem/vf610-ocotp.c | 301 
> > 
> >   3 files changed, 313 insertions(+)
> >   create mode 100644 drivers/nvmem/vf610-ocotp.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > index 0b33014..7af4c1d 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -47,4 +47,14 @@ config NVMEM_IMX_OCOTP
> >   This driver can also be built as a module. If so, the module
> >   will be called nvmem-imx-ocotp.
> >
> 
> Also please can you rebase it on top of char-misc-next?, This patch 
> would not apply as it is because of the above context.

Sure. Will rebase and send.

Thanks.

Regards,
Sanchayan.

> 
> 
> > +config NVMEM_VF610_OCOTP
> > +   tristate "VF610_SoCs OCOTP support"
> > +   depends on SOC_VF610 || COMPILE_TEST
> > +   help
> > + This is a driver for the 'OCOTP' peripheral available on Vybrid
> > + devices like VF5xx and VF6xx.
> > +
> > + This driver can also be built as a module. If so, the module will
> > + be called nvmem-vf610-ocotp.
> > +
> >   endif
> > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > index b512d77..8a1eea8 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -12,3 +12,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
> >   nvmem_sunxi_sid-y := sunxi_sid.o
> >   obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
> >   nvmem-imx-ocotp-y := imx-ocotp.o
> > +obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
> > +nvmem-vf610-ocotp-y:= vf610-ocotp.o
> > diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> > new file mode 100644
> > index 000..9e18156
> > --- /dev/null
> > +++ b/drivers/nvmem/vf610-ocotp.c
> > @@ -0,0 +1,301 @@
> > +/*
> > + * Copyright (C) 2015 Toradex AG.
> > + *
> > + * Author: Sanchayan Maity 
> > + *
> > + * Based on the barebox ocotp driver,
> > + * Copyright (c) 2010 Baruch Siach 
> > + * Orex Computed Radiography
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* OCOTP Register Offsets */
> > +#define OCOTP_CTRL_REG 0x00
> > +#define OCOTP_CTRL_SET 0x04
> > +#define OCOTP_CTRL_CLR 0x08
> > +#define OCOTP_TIMING   0x10
> > +#define OCOTP_DATA 0x20
> > +#define OCOTP_READ_CTRL_REG0x30
> > +#define OCOTP_READ_FUSE_DATA   0x40
> > +
> > +/* OCOTP Register bits and masks */
> > +#define OCOTP_CTRL_WR_UNLOCK   16
> > +#define OCOTP_CTRL_WR_UNLOCK_KEY   0x3E77
> > +#define OCOTP_CTRL_WR_UNLOCK_MASK  GENMASK(31, 16)
> > +#define OCOTP_CTRL_ADDR0
> > +#define OCOTP_CTRL_ADDR_MASK   GENMASK(6, 0)
> > +#define OCOTP_CTRL_RELOAD_SHADOWS  BIT(10)
> > +#define OCOTP_CTRL_ERROR   BIT(9)
> > +#define OCOTP_CTRL_BUSYBIT(8)
> > +
> > +#define OCOTP_TIMING_STROBE_READ   16
> > +#define OCOTP_TIMING_STROBE_READ_MASK  GENMASK(21, 16)
> > +#define OCOTP_TIMING_RELAX 12
> > +#define OCOTP_TIMING_RELAX_MASK  

Re: [PATCH v8 3/4] drivers: nvmem: Add Vybrid OCOTP support

[maitysanchayan]

Hello,

On 15-08-12 11:41:55, Srinivas Kandagatla wrote:
 Hi Sanchayan,
 
 Please run checkpatch before you send the patch next time.
 Look at Documentation/SubmittingPatches for more details.
 
 WARNING: line over 80 characters
 #225: FILE: drivers/nvmem/vf610-ocotp.c:174:
 + ret = vf610_ocotp_wait_busy(ocotp-base + 
 OCOTP_CTRL_REG);
 
 WARNING: line over 80 characters
 #237: FILE: drivers/nvmem/vf610-ocotp.c:186:
 + ret = vf610_ocotp_wait_busy(ocotp-base + 
 OCOTP_CTRL_REG);
 
 WARNING: line over 80 characters
 #244: FILE: drivers/nvmem/vf610-ocotp.c:193:
 + writel(OCOTP_CTRL_ERROR, ocotp-base + 
 OCOTP_CTRL_CLR);
 

I had. However splitting these lines seemed odd. Will split and fix.

 
 On 10/08/15 15:11, Sanchayan Maity wrote:
  The patch adds support for the On Chip One Time Programmable Peripheral
  (OCOTP) on the Vybrid platform.
 
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
drivers/nvmem/Kconfig   |  10 ++
drivers/nvmem/Makefile  |   2 +
drivers/nvmem/vf610-ocotp.c | 301 
  
3 files changed, 313 insertions(+)
create mode 100644 drivers/nvmem/vf610-ocotp.c
 
  diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
  index 0b33014..7af4c1d 100644
  --- a/drivers/nvmem/Kconfig
  +++ b/drivers/nvmem/Kconfig
  @@ -47,4 +47,14 @@ config NVMEM_IMX_OCOTP
This driver can also be built as a module. If so, the module
will be called nvmem-imx-ocotp.
 
 
 Also please can you rebase it on top of char-misc-next?, This patch 
 would not apply as it is because of the above context.

Sure. Will rebase and send.

Thanks.

Regards,
Sanchayan.

 
 
  +config NVMEM_VF610_OCOTP
  +   tristate VF610_SoCs OCOTP support
  +   depends on SOC_VF610 || COMPILE_TEST
  +   help
  + This is a driver for the 'OCOTP' peripheral available on Vybrid
  + devices like VF5xx and VF6xx.
  +
  + This driver can also be built as a module. If so, the module will
  + be called nvmem-vf610-ocotp.
  +
endif
  diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
  index b512d77..8a1eea8 100644
  --- a/drivers/nvmem/Makefile
  +++ b/drivers/nvmem/Makefile
  @@ -12,3 +12,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
nvmem_sunxi_sid-y := sunxi_sid.o
obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
nvmem-imx-ocotp-y := imx-ocotp.o
  +obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
  +nvmem-vf610-ocotp-y:= vf610-ocotp.o
  diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
  new file mode 100644
  index 000..9e18156
  --- /dev/null
  +++ b/drivers/nvmem/vf610-ocotp.c
  @@ -0,0 +1,301 @@
  +/*
  + * Copyright (C) 2015 Toradex AG.
  + *
  + * Author: Sanchayan Maity sanchayan.ma...@toradex.com
  + *
  + * Based on the barebox ocotp driver,
  + * Copyright (c) 2010 Baruch Siach bar...@tkos.co.il
  + * Orex Computed Radiography
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 and
  + * only version 2 as published by the Free Software Foundation.
  + *
  + * This program is distributed in the hope that it will be useful,
  + * but WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  + * GNU General Public License for more details.
  + */
  +
  +#include linux/clk.h
  +#include linux/delay.h
  +#include linux/device.h
  +#include linux/io.h
  +#include linux/module.h
  +#include linux/nvmem-provider.h
  +#include linux/of.h
  +#include linux/platform_device.h
  +#include linux/regmap.h
  +#include linux/slab.h
  +
  +/* OCOTP Register Offsets */
  +#define OCOTP_CTRL_REG 0x00
  +#define OCOTP_CTRL_SET 0x04
  +#define OCOTP_CTRL_CLR 0x08
  +#define OCOTP_TIMING   0x10
  +#define OCOTP_DATA 0x20
  +#define OCOTP_READ_CTRL_REG0x30
  +#define OCOTP_READ_FUSE_DATA   0x40
  +
  +/* OCOTP Register bits and masks */
  +#define OCOTP_CTRL_WR_UNLOCK   16
  +#define OCOTP_CTRL_WR_UNLOCK_KEY   0x3E77
  +#define OCOTP_CTRL_WR_UNLOCK_MASK  GENMASK(31, 16)
  +#define OCOTP_CTRL_ADDR0
  +#define OCOTP_CTRL_ADDR_MASK   GENMASK(6, 0)
  +#define OCOTP_CTRL_RELOAD_SHADOWS  BIT(10)
  +#define OCOTP_CTRL_ERROR   BIT(9)
  +#define OCOTP_CTRL_BUSYBIT(8)
  +
  +#define OCOTP_TIMING_STROBE_READ   16
  +#define OCOTP_TIMING_STROBE_READ_MASK  GENMASK(21, 16)
  +#define OCOTP_TIMING_RELAX 12
  +#define OCOTP_TIMING_RELAX_MASKGENMASK(15, 12)
  

Re: [PATCH v7 3/4] drivers: nvmem: Add Vybrid OCOTP support

[maitysanchayan]

Hello,

On 15-08-10 10:17:53, Srinivas Kandagatla wrote:
> Hi Sanchayan,
> 
> 
> Could you add Greg to the "to list" so that we can request him to pick 
> this via his tree.

Will add Greg in cc with the next revision.

> 
> 
> Few nits, other than that driver looks good.
> 
> 
> On 06/08/15 16:27, Sanchayan Maity wrote:
> > The patch adds support for the On Chip One Time Programmable Peripheral
> > (OCOTP) on the Vybrid platform.
> >
> > Signed-off-by: Sanchayan Maity 
> > ---
> >   drivers/nvmem/Kconfig   |  10 ++
> >   drivers/nvmem/Makefile  |   2 +
> >   drivers/nvmem/vf610-ocotp.c | 297 
> > 
> >   3 files changed, 309 insertions(+)
> >   create mode 100644 drivers/nvmem/vf610-ocotp.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > index 0b33014..bfd0c02 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -47,4 +47,14 @@ config NVMEM_IMX_OCOTP
> >   This driver can also be built as a module. If so, the module
> >   will be called nvmem-imx-ocotp.
> >
> > +config NVMEM_VF610_OCOTP
> > +   tristate "VF610_SoCs OCOTP support"
> > +   depends on SOC_VF610
> You could also add COMPILE_TEST which will ensure that its compile checked.

Ok.

> > +   help
> > + This is a driver for the 'OCOTP' peripheral available on Vybrid
> > + devices like VF5xx and VF6xx.
> > +
> > + This driver can also be built as a module. If so, the module will
> > + be called nvmem-vf610-ocotp.
> > +
> >   endif
> > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > index b512d77..8a1eea8 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -12,3 +12,5 @@ obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
> >   nvmem_sunxi_sid-y := sunxi_sid.o
> >   obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
> >   nvmem-imx-ocotp-y := imx-ocotp.o
> > +obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
> > +nvmem-vf610-ocotp-y:= vf610-ocotp.o
> > diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> > new file mode 100644
> > index 000..25ee701
> > --- /dev/null
> > +++ b/drivers/nvmem/vf610-ocotp.c
> > @@ -0,0 +1,297 @@
> > +/*
> > + * Copyright (C) 2015 Toradex AG.
> > + *
> > + * Author: Sanchayan Maity 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* OCOTP Register Offsets */
> > +#define OCOTP_CTRL_REG 0x00
> > +#define OCOTP_CTRL_SET 0x04
> > +#define OCOTP_CTRL_CLR 0x08
> > +#define OCOTP_TIMING   0x10
> > +#define OCOTP_DATA 0x20
> > +#define OCOTP_READ_CTRL_REG0x30
> > +#define OCOTP_READ_FUSE_DATA   0x40
> > +
> > +/* OCOTP Register bits and masks */
> > +#define OCOTP_CTRL_WR_UNLOCK   16
> > +#define OCOTP_CTRL_WR_UNLOCK_KEY   0x3E77
> > +#define OCOTP_CTRL_WR_UNLOCK_MASK  0x
> > +#define OCOTP_CTRL_ADDR0
> > +#define OCOTP_CTRL_ADDR_MASK   0x7F
> > +#define OCOTP_CTRL_RELOAD_SHADOWS  (0x1 << 10)
> > +#define OCOTP_CTRL_ERROR   (0x1 << 9)
> > +#define OCOTP_CTRL_BUSY(0x1 << 8)
> 
> we can use BIT and GENMASK variants here for most of the defines.

Ok.

> > +
> > +#define OCOTP_TIMING_STROBE_READ   16
> > +#define OCOTP_TIMING_STROBE_READ_MASK  0x003F
> > +#define OCOTP_TIMING_RELAX 12
> > +#define OCOTP_TIMING_RELAX_MASK0xF000
> > +#define OCOTP_TIMING_STROBE_PROG   0
> > +#define OCOTP_TIMING_STROBE_PROG_MASK  0x0FFF
> > +
> > +#define OCOTP_READ_CTRL_READ_FUSE  0x1
> > +
> > +#define VF610_OCOTP_TIMEOUT10
> > +
> > +#define BF(value, field)   (((value) << field) & field##_MASK)
> > +
> > +#define DEF_RELAX  20
> > +
> > +static const int base_to_fuse_addr_mappings[][2] = {
> > +   {0x400, 0x00},
> > +   {0x410, 0x01},
> > +   {0x420, 0x02},
> > +   {0x450, 0x05},
> > +   {0x4F0, 0x0F},
> > +   {0x600, 0x20},
> > +   {0x610, 0x21},
> > +   {0x620, 0x22},
> > +   {0x630, 0x23},
> > +   {0x640, 0x24},
> > +   

Re: [PATCH v7 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver

[maitysanchayan]

Hello,

On 15-08-10 10:18:01, Srinivas Kandagatla wrote:
> 
> 
> On 06/08/15 16:27, Sanchayan Maity wrote:
> > Add the devicetree bindings for the Freescale Vybrid On-Chip
> > OTP driver.
> >
> > Signed-off-by: Sanchayan Maity 
> > ---
> >   .../devicetree/bindings/nvmem/vf610-ocotp.txt| 20 
> > 
> >   1 file changed, 20 insertions(+)
> >   create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt 
> > b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > new file mode 100644
> > index 000..5556810
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
> > @@ -0,0 +1,20 @@
> > +On-Chip OTP Memory for Freescale Vybrid
> > +
> > +Required Properties:
> > +  compatible:
> > +  - "fsl,vf610-ocotp" for VF5xx/VF6xx
> > +  #address-cells : Should be 1
> > +  #size-cells : Should be 1
> > +  reg : Address and length of OTP controller registers
> 
> Is there a reason to not add clocks property in to the bindings?

An error on my part. Will fix with the next revision.

- Sanchayan.

> 
> > +
> > +Example for Vybrid VF5xx/VF6xx:
> > +
> > +   ocotp: ocotp@400a5000 {
> > +   compatible = "fsl,vf610-ocotp";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   reg = <0x400a5000 0xD00>;
> > +   clocks = < VF610_CLK_OCOTP>;
> > +   clock-names = "ocotp";
> > +   };
> > +
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/