[PATCH v6 04/15] net: e100: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Acked-by: Jeff Kirsher 
Tested-by: Peter Senna Tschudin 
---
 drivers/net/ethernet/intel/e100.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c 
b/drivers/net/ethernet/intel/e100.c
index 2b7323d..d1002c2 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -607,7 +607,7 @@ struct nic {
struct mem *mem;
dma_addr_t dma_addr;
 
-   struct pci_pool *cbs_pool;
+   struct dma_pool *cbs_pool;
dma_addr_t cbs_dma_addr;
u8 adaptive_ifs;
u8 tx_threshold;
@@ -1892,7 +1892,7 @@ static void e100_clean_cbs(struct nic *nic)
nic->cb_to_clean = nic->cb_to_clean->next;
nic->cbs_avail++;
}
-   pci_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
+   dma_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
nic->cbs = NULL;
nic->cbs_avail = 0;
}
@@ -1910,7 +1910,7 @@ static int e100_alloc_cbs(struct nic *nic)
nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL;
nic->cbs_avail = 0;
 
-   nic->cbs = pci_pool_alloc(nic->cbs_pool, GFP_KERNEL,
+   nic->cbs = dma_pool_alloc(nic->cbs_pool, GFP_KERNEL,
  >cbs_dma_addr);
if (!nic->cbs)
return -ENOMEM;
@@ -2958,8 +2958,8 @@ static int e100_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
netif_err(nic, probe, nic->netdev, "Cannot register net device, 
aborting\n");
goto err_out_free;
}
-   nic->cbs_pool = pci_pool_create(netdev->name,
-  nic->pdev,
+   nic->cbs_pool = dma_pool_create(netdev->name,
+  >pdev->dev,
   nic->params.cbs.max * sizeof(struct cb),
   sizeof(u32),
   0);
@@ -2999,7 +2999,7 @@ static void e100_remove(struct pci_dev *pdev)
unregister_netdev(netdev);
e100_free(nic);
pci_iounmap(pdev, nic->csr);
-   pci_pool_destroy(nic->cbs_pool);
+   dma_pool_destroy(nic->cbs_pool);
free_netdev(netdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3



[PATCH v6 04/15] net: e100: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Acked-by: Jeff Kirsher 
Tested-by: Peter Senna Tschudin 
---
 drivers/net/ethernet/intel/e100.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c 
b/drivers/net/ethernet/intel/e100.c
index 2b7323d..d1002c2 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -607,7 +607,7 @@ struct nic {
struct mem *mem;
dma_addr_t dma_addr;
 
-   struct pci_pool *cbs_pool;
+   struct dma_pool *cbs_pool;
dma_addr_t cbs_dma_addr;
u8 adaptive_ifs;
u8 tx_threshold;
@@ -1892,7 +1892,7 @@ static void e100_clean_cbs(struct nic *nic)
nic->cb_to_clean = nic->cb_to_clean->next;
nic->cbs_avail++;
}
-   pci_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
+   dma_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
nic->cbs = NULL;
nic->cbs_avail = 0;
}
@@ -1910,7 +1910,7 @@ static int e100_alloc_cbs(struct nic *nic)
nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL;
nic->cbs_avail = 0;
 
-   nic->cbs = pci_pool_alloc(nic->cbs_pool, GFP_KERNEL,
+   nic->cbs = dma_pool_alloc(nic->cbs_pool, GFP_KERNEL,
  >cbs_dma_addr);
if (!nic->cbs)
return -ENOMEM;
@@ -2958,8 +2958,8 @@ static int e100_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
netif_err(nic, probe, nic->netdev, "Cannot register net device, 
aborting\n");
goto err_out_free;
}
-   nic->cbs_pool = pci_pool_create(netdev->name,
-  nic->pdev,
+   nic->cbs_pool = dma_pool_create(netdev->name,
+  >pdev->dev,
   nic->params.cbs.max * sizeof(struct cb),
   sizeof(u32),
   0);
@@ -2999,7 +2999,7 @@ static void e100_remove(struct pci_dev *pdev)
unregister_netdev(netdev);
e100_free(nic);
pci_iounmap(pdev, nic->csr);
-   pci_pool_destroy(nic->cbs_pool);
+   dma_pool_destroy(nic->cbs_pool);
free_netdev(netdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3



[PATCH v6 10/15] scsi: lpfc: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
some comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/lpfc/lpfc.h   |  14 +++---
 drivers/scsi/lpfc/lpfc_init.c  |  16 +++
 drivers/scsi/lpfc/lpfc_mem.c   | 106 -
 drivers/scsi/lpfc/lpfc_nvme.c  |   6 +--
 drivers/scsi/lpfc/lpfc_nvmet.c |   4 +-
 drivers/scsi/lpfc/lpfc_scsi.c  |  12 ++---
 6 files changed, 77 insertions(+), 81 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 257bbdd..c6f82db 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -935,13 +935,13 @@ struct lpfc_hba {
struct list_head active_rrq_list;
spinlock_t hbalock;
 
-   /* pci_mem_pools */
-   struct pci_pool *lpfc_sg_dma_buf_pool;
-   struct pci_pool *lpfc_mbuf_pool;
-   struct pci_pool *lpfc_hrb_pool; /* header receive buffer pool */
-   struct pci_pool *lpfc_drb_pool; /* data receive buffer pool */
-   struct pci_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
-   struct pci_pool *txrdy_payload_pool;
+   /* dma_mem_pools */
+   struct dma_pool *lpfc_sg_dma_buf_pool;
+   struct dma_pool *lpfc_mbuf_pool;
+   struct dma_pool *lpfc_hrb_pool; /* header receive buffer pool */
+   struct dma_pool *lpfc_drb_pool; /* data receive buffer pool */
+   struct dma_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
+   struct dma_pool *txrdy_payload_pool;
struct lpfc_dma_pool lpfc_mbuf_safety_pool;
 
mempool_t *mbox_mem_pool;
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 2697d49..0ffdd722 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3151,7 +3151,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_put,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3162,7 +3162,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_get,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3193,7 +3193,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_put, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3204,7 +3204,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_get, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3517,7 +3517,7 @@ lpfc_sli4_scsi_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, psb,
 struct lpfc_scsi_buf, list);
if (psb) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  psb->data, psb->dma_handle);
kfree(psb);
}
@@ -3652,7 +3652,7 @@ lpfc_sli4_nvme_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, lpfc_ncmd,
 struct lpfc_nvme_buf, list);
if (lpfc_ncmd) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
@@ -6673,8 +6673,8 @@ lpfc_create_shost(struct 

[PATCH v6 10/15] scsi: lpfc: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
some comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/lpfc/lpfc.h   |  14 +++---
 drivers/scsi/lpfc/lpfc_init.c  |  16 +++
 drivers/scsi/lpfc/lpfc_mem.c   | 106 -
 drivers/scsi/lpfc/lpfc_nvme.c  |   6 +--
 drivers/scsi/lpfc/lpfc_nvmet.c |   4 +-
 drivers/scsi/lpfc/lpfc_scsi.c  |  12 ++---
 6 files changed, 77 insertions(+), 81 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 257bbdd..c6f82db 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -935,13 +935,13 @@ struct lpfc_hba {
struct list_head active_rrq_list;
spinlock_t hbalock;
 
-   /* pci_mem_pools */
-   struct pci_pool *lpfc_sg_dma_buf_pool;
-   struct pci_pool *lpfc_mbuf_pool;
-   struct pci_pool *lpfc_hrb_pool; /* header receive buffer pool */
-   struct pci_pool *lpfc_drb_pool; /* data receive buffer pool */
-   struct pci_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
-   struct pci_pool *txrdy_payload_pool;
+   /* dma_mem_pools */
+   struct dma_pool *lpfc_sg_dma_buf_pool;
+   struct dma_pool *lpfc_mbuf_pool;
+   struct dma_pool *lpfc_hrb_pool; /* header receive buffer pool */
+   struct dma_pool *lpfc_drb_pool; /* data receive buffer pool */
+   struct dma_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
+   struct dma_pool *txrdy_payload_pool;
struct lpfc_dma_pool lpfc_mbuf_safety_pool;
 
mempool_t *mbox_mem_pool;
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 2697d49..0ffdd722 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3151,7 +3151,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_put,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3162,7 +3162,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_get,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3193,7 +3193,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_put, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3204,7 +3204,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_get, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3517,7 +3517,7 @@ lpfc_sli4_scsi_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, psb,
 struct lpfc_scsi_buf, list);
if (psb) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  psb->data, psb->dma_handle);
kfree(psb);
}
@@ -3652,7 +3652,7 @@ lpfc_sli4_nvme_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, lpfc_ncmd,
 struct lpfc_nvme_buf, list);
if (lpfc_ncmd) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
@@ -6673,8 +6673,8 @@ lpfc_create_shost(struct lpfc_hba *phba)
if (phba->nvmet_support) {
  

[PATCH v6 07/15] wireless: ipw2200: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 5ef3c5c..93dfe47 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -3211,7 +3211,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
struct fw_chunk *chunk;
int total_nr = 0;
int i;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
void **virts;
dma_addr_t *phys;
 
@@ -3228,9 +3228,10 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
kfree(virts);
return -ENOMEM;
}
-   pool = pci_pool_create("ipw2200", priv->pci_dev, CB_MAX_LENGTH, 0, 0);
+   pool = dma_pool_create("ipw2200", >pci_dev->dev, CB_MAX_LENGTH, 0,
+  0);
if (!pool) {
-   IPW_ERROR("pci_pool_create failed\n");
+   IPW_ERROR("dma_pool_create failed\n");
kfree(phys);
kfree(virts);
return -ENOMEM;
@@ -3255,7 +3256,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
 
nr = (chunk_len + CB_MAX_LENGTH - 1) / CB_MAX_LENGTH;
for (i = 0; i < nr; i++) {
-   virts[total_nr] = pci_pool_alloc(pool, GFP_KERNEL,
+   virts[total_nr] = dma_pool_alloc(pool, GFP_KERNEL,
 [total_nr]);
if (!virts[total_nr]) {
ret = -ENOMEM;
@@ -3299,9 +3300,9 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
}
  out:
for (i = 0; i < total_nr; i++)
-   pci_pool_free(pool, virts[i], phys[i]);
+   dma_pool_free(pool, virts[i], phys[i]);
 
-   pci_pool_destroy(pool);
+   dma_pool_destroy(pool);
kfree(phys);
kfree(virts);
 
-- 
2.9.3



[PATCH v6 11/15] scsi: megaraid: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
Acked-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_mbox.c   | 33 +++
 drivers/scsi/megaraid/megaraid_mm.c | 32 +++---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 29 +++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 66 +
 4 files changed, 77 insertions(+), 83 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_mbox.c 
b/drivers/scsi/megaraid/megaraid_mbox.c
index f0987f2..7dfc2e2 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -1153,8 +1153,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
 
// Allocate memory for 16-bytes aligned mailboxes
-   raid_dev->mbox_pool_handle = pci_pool_create("megaraid mbox pool",
-   adapter->pdev,
+   raid_dev->mbox_pool_handle = dma_pool_create("megaraid mbox pool",
+   >pdev->dev,
sizeof(mbox64_t) + 16,
16, 0);
 
@@ -1164,7 +1164,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
mbox_pci_blk = raid_dev->mbox_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   mbox_pci_blk[i].vaddr = pci_pool_alloc(
+   mbox_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->mbox_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1181,8 +1181,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 * share common memory pool. Passthru structures piggyback on memory
 * allocted to extended passthru since passthru is smaller of the two
 */
-   raid_dev->epthru_pool_handle = pci_pool_create("megaraid mbox pthru",
-   adapter->pdev, sizeof(mraid_epassthru_t), 128, 0);
+   raid_dev->epthru_pool_handle = dma_pool_create("megaraid mbox pthru",
+   >pdev->dev, sizeof(mraid_epassthru_t), 128, 0);
 
if (raid_dev->epthru_pool_handle == NULL) {
goto fail_setup_dma_pool;
@@ -1190,7 +1190,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   epthru_pci_blk[i].vaddr = pci_pool_alloc(
+   epthru_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->epthru_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1202,8 +1202,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
// Allocate memory for each scatter-gather list. Request for 512 bytes
// alignment for each sg list
-   raid_dev->sg_pool_handle = pci_pool_create("megaraid mbox sg",
-   adapter->pdev,
+   raid_dev->sg_pool_handle = dma_pool_create("megaraid mbox sg",
+   >pdev->dev,
sizeof(mbox_sgl64) * MBOX_MAX_SG_SIZE,
512, 0);
 
@@ -1213,7 +1213,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   sg_pci_blk[i].vaddr = pci_pool_alloc(
+   sg_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->sg_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1249,29 +1249,26 @@ megaraid_mbox_teardown_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && sg_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
+   dma_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
sg_pci_blk[i].dma_addr);
}
-   if (raid_dev->sg_pool_handle)
-   pci_pool_destroy(raid_dev->sg_pool_handle);
+   dma_pool_destroy(raid_dev->sg_pool_handle);
 
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && epthru_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->epthru_pool_handle,
+   dma_pool_free(raid_dev->epthru_pool_handle,
epthru_pci_blk[i].vaddr, epthru_pci_blk[i].dma_addr);
}
-   if (raid_dev->epthru_pool_handle)
-  

[PATCH v6 09/15] scsi: csiostor: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
the name of some variables and the content of comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/csiostor/csio_hw.h   |  2 +-
 drivers/scsi/csiostor/csio_init.c | 11 ++-
 drivers/scsi/csiostor/csio_scsi.c |  6 +++---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 029bef8..55b04fc 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -465,7 +465,7 @@ struct csio_hw {
struct csio_pport   pport[CSIO_MAX_PPORTS]; /* Ports (XGMACs) */
struct csio_hw_params   params; /* Hw parameters */
 
-   struct pci_pool *scsi_pci_pool; /* PCI pool for SCSI */
+   struct dma_pool *scsi_dma_pool; /* DMA pool for SCSI */
mempool_t   *mb_mempool;/* Mailbox memory pool*/
mempool_t   *rnode_mempool; /* rnode memory pool */
 
diff --git a/drivers/scsi/csiostor/csio_init.c 
b/drivers/scsi/csiostor/csio_init.c
index dbe416f..292964c 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -485,9 +485,10 @@ csio_resource_alloc(struct csio_hw *hw)
if (!hw->rnode_mempool)
goto err_free_mb_mempool;
 
-   hw->scsi_pci_pool = pci_pool_create("csio_scsi_pci_pool", hw->pdev,
-   CSIO_SCSI_RSP_LEN, 8, 0);
-   if (!hw->scsi_pci_pool)
+   hw->scsi_dma_pool = dma_pool_create("csio_scsi_dma_pool",
+   >pdev->dev, CSIO_SCSI_RSP_LEN,
+   8, 0);
+   if (!hw->scsi_dma_pool)
goto err_free_rn_pool;
 
return 0;
@@ -505,8 +506,8 @@ csio_resource_alloc(struct csio_hw *hw)
 static void
 csio_resource_free(struct csio_hw *hw)
 {
-   pci_pool_destroy(hw->scsi_pci_pool);
-   hw->scsi_pci_pool = NULL;
+   dma_pool_destroy(hw->scsi_dma_pool);
+   hw->scsi_dma_pool = NULL;
mempool_destroy(hw->rnode_mempool);
hw->rnode_mempool = NULL;
mempool_destroy(hw->mb_mempool);
diff --git a/drivers/scsi/csiostor/csio_scsi.c 
b/drivers/scsi/csiostor/csio_scsi.c
index a1ff75f..dab0d3f 100644
--- a/drivers/scsi/csiostor/csio_scsi.c
+++ b/drivers/scsi/csiostor/csio_scsi.c
@@ -2445,7 +2445,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
 
/* Allocate Dma buffers for Response Payload */
dma_buf = >dma_buf;
-   dma_buf->vaddr = pci_pool_alloc(hw->scsi_pci_pool, GFP_KERNEL,
+   dma_buf->vaddr = dma_pool_alloc(hw->scsi_dma_pool, GFP_KERNEL,
_buf->paddr);
if (!dma_buf->vaddr) {
csio_err(hw,
@@ -2485,7 +2485,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
@@ -2516,7 +2516,7 @@ csio_scsim_exit(struct csio_scsim *scm)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(scm->hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(scm->hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
-- 
2.9.3



[PATCH v6 07/15] wireless: ipw2200: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 5ef3c5c..93dfe47 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -3211,7 +3211,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
struct fw_chunk *chunk;
int total_nr = 0;
int i;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
void **virts;
dma_addr_t *phys;
 
@@ -3228,9 +3228,10 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
kfree(virts);
return -ENOMEM;
}
-   pool = pci_pool_create("ipw2200", priv->pci_dev, CB_MAX_LENGTH, 0, 0);
+   pool = dma_pool_create("ipw2200", >pci_dev->dev, CB_MAX_LENGTH, 0,
+  0);
if (!pool) {
-   IPW_ERROR("pci_pool_create failed\n");
+   IPW_ERROR("dma_pool_create failed\n");
kfree(phys);
kfree(virts);
return -ENOMEM;
@@ -3255,7 +3256,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
 
nr = (chunk_len + CB_MAX_LENGTH - 1) / CB_MAX_LENGTH;
for (i = 0; i < nr; i++) {
-   virts[total_nr] = pci_pool_alloc(pool, GFP_KERNEL,
+   virts[total_nr] = dma_pool_alloc(pool, GFP_KERNEL,
 [total_nr]);
if (!virts[total_nr]) {
ret = -ENOMEM;
@@ -3299,9 +3300,9 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
}
  out:
for (i = 0; i < total_nr; i++)
-   pci_pool_free(pool, virts[i], phys[i]);
+   dma_pool_free(pool, virts[i], phys[i]);
 
-   pci_pool_destroy(pool);
+   dma_pool_destroy(pool);
kfree(phys);
kfree(virts);
 
-- 
2.9.3



[PATCH v6 11/15] scsi: megaraid: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
Acked-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_mbox.c   | 33 +++
 drivers/scsi/megaraid/megaraid_mm.c | 32 +++---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 29 +++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 66 +
 4 files changed, 77 insertions(+), 83 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_mbox.c 
b/drivers/scsi/megaraid/megaraid_mbox.c
index f0987f2..7dfc2e2 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -1153,8 +1153,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
 
// Allocate memory for 16-bytes aligned mailboxes
-   raid_dev->mbox_pool_handle = pci_pool_create("megaraid mbox pool",
-   adapter->pdev,
+   raid_dev->mbox_pool_handle = dma_pool_create("megaraid mbox pool",
+   >pdev->dev,
sizeof(mbox64_t) + 16,
16, 0);
 
@@ -1164,7 +1164,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
mbox_pci_blk = raid_dev->mbox_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   mbox_pci_blk[i].vaddr = pci_pool_alloc(
+   mbox_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->mbox_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1181,8 +1181,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 * share common memory pool. Passthru structures piggyback on memory
 * allocted to extended passthru since passthru is smaller of the two
 */
-   raid_dev->epthru_pool_handle = pci_pool_create("megaraid mbox pthru",
-   adapter->pdev, sizeof(mraid_epassthru_t), 128, 0);
+   raid_dev->epthru_pool_handle = dma_pool_create("megaraid mbox pthru",
+   >pdev->dev, sizeof(mraid_epassthru_t), 128, 0);
 
if (raid_dev->epthru_pool_handle == NULL) {
goto fail_setup_dma_pool;
@@ -1190,7 +1190,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   epthru_pci_blk[i].vaddr = pci_pool_alloc(
+   epthru_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->epthru_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1202,8 +1202,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
// Allocate memory for each scatter-gather list. Request for 512 bytes
// alignment for each sg list
-   raid_dev->sg_pool_handle = pci_pool_create("megaraid mbox sg",
-   adapter->pdev,
+   raid_dev->sg_pool_handle = dma_pool_create("megaraid mbox sg",
+   >pdev->dev,
sizeof(mbox_sgl64) * MBOX_MAX_SG_SIZE,
512, 0);
 
@@ -1213,7 +1213,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   sg_pci_blk[i].vaddr = pci_pool_alloc(
+   sg_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->sg_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1249,29 +1249,26 @@ megaraid_mbox_teardown_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && sg_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
+   dma_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
sg_pci_blk[i].dma_addr);
}
-   if (raid_dev->sg_pool_handle)
-   pci_pool_destroy(raid_dev->sg_pool_handle);
+   dma_pool_destroy(raid_dev->sg_pool_handle);
 
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && epthru_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->epthru_pool_handle,
+   dma_pool_free(raid_dev->epthru_pool_handle,
epthru_pci_blk[i].vaddr, epthru_pci_blk[i].dma_addr);
}
-   if (raid_dev->epthru_pool_handle)
-   pci_pool_destroy(raid_dev->epthru_pool_handle);
+   

[PATCH v6 09/15] scsi: csiostor: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
the name of some variables and the content of comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/csiostor/csio_hw.h   |  2 +-
 drivers/scsi/csiostor/csio_init.c | 11 ++-
 drivers/scsi/csiostor/csio_scsi.c |  6 +++---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 029bef8..55b04fc 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -465,7 +465,7 @@ struct csio_hw {
struct csio_pport   pport[CSIO_MAX_PPORTS]; /* Ports (XGMACs) */
struct csio_hw_params   params; /* Hw parameters */
 
-   struct pci_pool *scsi_pci_pool; /* PCI pool for SCSI */
+   struct dma_pool *scsi_dma_pool; /* DMA pool for SCSI */
mempool_t   *mb_mempool;/* Mailbox memory pool*/
mempool_t   *rnode_mempool; /* rnode memory pool */
 
diff --git a/drivers/scsi/csiostor/csio_init.c 
b/drivers/scsi/csiostor/csio_init.c
index dbe416f..292964c 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -485,9 +485,10 @@ csio_resource_alloc(struct csio_hw *hw)
if (!hw->rnode_mempool)
goto err_free_mb_mempool;
 
-   hw->scsi_pci_pool = pci_pool_create("csio_scsi_pci_pool", hw->pdev,
-   CSIO_SCSI_RSP_LEN, 8, 0);
-   if (!hw->scsi_pci_pool)
+   hw->scsi_dma_pool = dma_pool_create("csio_scsi_dma_pool",
+   >pdev->dev, CSIO_SCSI_RSP_LEN,
+   8, 0);
+   if (!hw->scsi_dma_pool)
goto err_free_rn_pool;
 
return 0;
@@ -505,8 +506,8 @@ csio_resource_alloc(struct csio_hw *hw)
 static void
 csio_resource_free(struct csio_hw *hw)
 {
-   pci_pool_destroy(hw->scsi_pci_pool);
-   hw->scsi_pci_pool = NULL;
+   dma_pool_destroy(hw->scsi_dma_pool);
+   hw->scsi_dma_pool = NULL;
mempool_destroy(hw->rnode_mempool);
hw->rnode_mempool = NULL;
mempool_destroy(hw->mb_mempool);
diff --git a/drivers/scsi/csiostor/csio_scsi.c 
b/drivers/scsi/csiostor/csio_scsi.c
index a1ff75f..dab0d3f 100644
--- a/drivers/scsi/csiostor/csio_scsi.c
+++ b/drivers/scsi/csiostor/csio_scsi.c
@@ -2445,7 +2445,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
 
/* Allocate Dma buffers for Response Payload */
dma_buf = >dma_buf;
-   dma_buf->vaddr = pci_pool_alloc(hw->scsi_pci_pool, GFP_KERNEL,
+   dma_buf->vaddr = dma_pool_alloc(hw->scsi_dma_pool, GFP_KERNEL,
_buf->paddr);
if (!dma_buf->vaddr) {
csio_err(hw,
@@ -2485,7 +2485,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
@@ -2516,7 +2516,7 @@ csio_scsim_exit(struct csio_scsim *scm)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(scm->hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(scm->hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
-- 
2.9.3



Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-19 Thread Michael Zoran
On Sun, 2017-03-19 at 13:58 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Mar 2017 17:34:36 -0700
> Eric Anholt  escreveu:
> 
> > Mauro Carvalho Chehab  writes:
> > 
> > > Em Wed, 15 Mar 2017 18:46:24 -0700
> > > Michael Zoran  escreveu:
> > > 
> > > > On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:
> > > > 
> > > > > No, I didn't. Thanks! Applied it but, unfortunately, didn't
> > > > > work.
> > > > > Perhaps I'm missing some other patch. I'm compiling it from
> > > > > the Greg's staging tree (branch staging-next):
> > > > >   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/
> > > > > staging.
> > > > > git/log/?h=staging-next
> > > > > 
> > > > > Btw, as I'm running Raspbian, and didn't want to use compat32
> > > > > bits, 
> > > > > I'm compiling the Kernel as an arm32 bits Kernel.
> > > > > 
> > > > > I did a small trick to build the DTB on arm32:
> > > > > 
> > > > >   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-
> > > > > b.dts
> > > > > arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> > > > >   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
> > > > > arch/arm/boot/dts/bcm2837.dtsi
> > > > >   git checkout arch/arm/boot/dts/Makefile
> > > > >   sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb
> > > > > bcm2837-rpi-3-
> > > > > b.dtb," a && mv a arch/arm/boot/dts/Makefile
> > > > >   
> > > > 
> > > > Two other hacks are currently needed to get the camera to work:
> > > > 
> > > > 1. Add this to config.txt(This required to get the firmware to
> > > > detect
> > > > the camera)
> > > > 
> > > > start_x=1
> > > > gpu_mem=128
> > > 
> > > I had this already.
> > > 
> > > > 
> > > > 2. VC4 is incompatible with the firmware at this time, so you
> > > > need 
> > > > to presently munge the build configuration. What you do is
> > > > leave
> > > > simplefb in the build config(I'm assuming you already have
> > > > that), but
> > > > you will need to remove VC4 from the config.
> > > > 
> > > > The firmware currently adds a node for a simplefb for debugging
> > > > purposes to show the boot log.  Surprisingly, this is still
> > > > good enough
> > > > for basic usage and testing.  
> > > 
> > > That solved the issue. Thanks! It would be good to add a notice
> > > about that at the TODO, not let it build if DRM_VC4.
> > > 
> > > Please consider applying the enclosed path.
> > 
> > The VC4 incompatibility (camera firmware's AWB ends up briefly
> > using the
> > GPU, without coordinating with the Linux driver) is supposed to be
> > fixed
> > in current firmware
> > (https://github.com/raspberrypi/firmware/issues/760#issuecomment-28
> > 7391025)
> 
> With the current firmware, when X starts, the screen becomes blank,
> with upstream Kernel (it works with the downstream Kernel shipped
> with 
> the firmware).
> 
> Maybe something changed at DT?
> 
> Thanks,
> Mauro

Hi, exactly which DT are you using and which drivers are you using for
video. If this is a RPI 3, then as you know VC4 doesn't work due to the
HDMI hotplug issue. So I'm not 100% sure how you were getting video.

A working DT that I tried this morning with the current firmware is
posted here:
http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/005924
.html

It even works with minecraft_pi!





Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-19 Thread Michael Zoran
On Sun, 2017-03-19 at 13:58 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Mar 2017 17:34:36 -0700
> Eric Anholt  escreveu:
> 
> > Mauro Carvalho Chehab  writes:
> > 
> > > Em Wed, 15 Mar 2017 18:46:24 -0700
> > > Michael Zoran  escreveu:
> > > 
> > > > On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:
> > > > 
> > > > > No, I didn't. Thanks! Applied it but, unfortunately, didn't
> > > > > work.
> > > > > Perhaps I'm missing some other patch. I'm compiling it from
> > > > > the Greg's staging tree (branch staging-next):
> > > > >   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/
> > > > > staging.
> > > > > git/log/?h=staging-next
> > > > > 
> > > > > Btw, as I'm running Raspbian, and didn't want to use compat32
> > > > > bits, 
> > > > > I'm compiling the Kernel as an arm32 bits Kernel.
> > > > > 
> > > > > I did a small trick to build the DTB on arm32:
> > > > > 
> > > > >   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-
> > > > > b.dts
> > > > > arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> > > > >   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
> > > > > arch/arm/boot/dts/bcm2837.dtsi
> > > > >   git checkout arch/arm/boot/dts/Makefile
> > > > >   sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb
> > > > > bcm2837-rpi-3-
> > > > > b.dtb," a && mv a arch/arm/boot/dts/Makefile
> > > > >   
> > > > 
> > > > Two other hacks are currently needed to get the camera to work:
> > > > 
> > > > 1. Add this to config.txt(This required to get the firmware to
> > > > detect
> > > > the camera)
> > > > 
> > > > start_x=1
> > > > gpu_mem=128
> > > 
> > > I had this already.
> > > 
> > > > 
> > > > 2. VC4 is incompatible with the firmware at this time, so you
> > > > need 
> > > > to presently munge the build configuration. What you do is
> > > > leave
> > > > simplefb in the build config(I'm assuming you already have
> > > > that), but
> > > > you will need to remove VC4 from the config.
> > > > 
> > > > The firmware currently adds a node for a simplefb for debugging
> > > > purposes to show the boot log.  Surprisingly, this is still
> > > > good enough
> > > > for basic usage and testing.  
> > > 
> > > That solved the issue. Thanks! It would be good to add a notice
> > > about that at the TODO, not let it build if DRM_VC4.
> > > 
> > > Please consider applying the enclosed path.
> > 
> > The VC4 incompatibility (camera firmware's AWB ends up briefly
> > using the
> > GPU, without coordinating with the Linux driver) is supposed to be
> > fixed
> > in current firmware
> > (https://github.com/raspberrypi/firmware/issues/760#issuecomment-28
> > 7391025)
> 
> With the current firmware, when X starts, the screen becomes blank,
> with upstream Kernel (it works with the downstream Kernel shipped
> with 
> the firmware).
> 
> Maybe something changed at DT?
> 
> Thanks,
> Mauro

Hi, exactly which DT are you using and which drivers are you using for
video. If this is a RPI 3, then as you know VC4 doesn't work due to the
HDMI hotplug issue. So I'm not 100% sure how you were getting video.

A working DT that I tried this morning with the current firmware is
posted here:
http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/005924
.html

It even works with minecraft_pi!





[PATCH v6 13/15] scsi: mvsas: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mvsas/mv_init.c | 6 +++---
 drivers/scsi/mvsas/mv_sas.c  | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 8280046..41d2276 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -125,8 +125,7 @@ static void mvs_free(struct mvs_info *mvi)
else
slot_nr = MVS_CHIP_SLOT_SZ;
 
-   if (mvi->dma_pool)
-   pci_pool_destroy(mvi->dma_pool);
+   dma_pool_destroy(mvi->dma_pool);
 
if (mvi->tx)
dma_free_coherent(mvi->dev,
@@ -296,7 +295,8 @@ static int mvs_alloc(struct mvs_info *mvi, struct Scsi_Host 
*shost)
goto err_out;
 
sprintf(pool_name, "%s%d", "mvs_dma_pool", mvi->id);
-   mvi->dma_pool = pci_pool_create(pool_name, mvi->pdev, MVS_SLOT_BUF_SZ, 
16, 0);
+   mvi->dma_pool = dma_pool_create(pool_name, >pdev->dev,
+   MVS_SLOT_BUF_SZ, 16, 0);
if (!mvi->dma_pool) {
printk(KERN_DEBUG "failed to create dma pool %s.\n", 
pool_name);
goto err_out;
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index c7cc803..ee81d10 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -790,7 +790,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
slot->n_elem = n_elem;
slot->slot_tag = tag;
 
-   slot->buf = pci_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
+   slot->buf = dma_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
if (!slot->buf) {
rc = -ENOMEM;
goto err_out_tag;
@@ -840,7 +840,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
return rc;
 
 err_out_slot_buf:
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
 err_out_tag:
mvs_tag_free(mvi, tag);
 err_out:
@@ -918,7 +918,7 @@ static void mvs_slot_task_free(struct mvs_info *mvi, struct 
sas_task *task,
}
 
if (slot->buf) {
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
slot->buf = NULL;
}
list_del_init(>entry);
-- 
2.9.3



[PATCH v6 12/15] scsi: mpt3sas: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 73 +
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 5b7aec5..5ae1c23 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3200,9 +3200,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->sense) {
-   pci_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
-   if (ioc->sense_dma_pool)
-   pci_pool_destroy(ioc->sense_dma_pool);
+   dma_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
+   dma_pool_destroy(ioc->sense_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"sense_pool(0x%p): free\n",
ioc->name, ioc->sense));
@@ -3210,9 +3209,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply) {
-   pci_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
-   if (ioc->reply_dma_pool)
-   pci_pool_destroy(ioc->reply_dma_pool);
+   dma_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
+   dma_pool_destroy(ioc->reply_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_pool(0x%p): free\n",
ioc->name, ioc->reply));
@@ -3220,10 +3218,9 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply_free) {
-   pci_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
+   dma_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
ioc->reply_free_dma);
-   if (ioc->reply_free_dma_pool)
-   pci_pool_destroy(ioc->reply_free_dma_pool);
+   dma_pool_destroy(ioc->reply_free_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_free_pool(0x%p): free\n",
ioc->name, ioc->reply_free));
@@ -3234,7 +3231,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
do {
rps = >reply_post[i];
if (rps->reply_post_free) {
-   pci_pool_free(
+   dma_pool_free(
ioc->reply_post_free_dma_pool,
rps->reply_post_free,
rps->reply_post_free_dma);
@@ -3246,8 +3243,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
} while (ioc->rdpq_array_enable &&
   (++i < ioc->reply_queue_count));
 
-   if (ioc->reply_post_free_dma_pool)
-   pci_pool_destroy(ioc->reply_post_free_dma_pool);
+   dma_pool_destroy(ioc->reply_post_free_dma_pool);
kfree(ioc->reply_post);
}
 
@@ -3268,12 +3264,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
if (ioc->chain_lookup) {
for (i = 0; i < ioc->chain_depth; i++) {
if (ioc->chain_lookup[i].chain_buffer)
-   pci_pool_free(ioc->chain_dma_pool,
+   dma_pool_free(ioc->chain_dma_pool,
ioc->chain_lookup[i].chain_buffer,
ioc->chain_lookup[i].chain_buffer_dma);
}
-   if (ioc->chain_dma_pool)
-   pci_pool_destroy(ioc->chain_dma_pool);
+   dma_pool_destroy(ioc->chain_dma_pool);
free_pages((ulong)ioc->chain_lookup, ioc->chain_pages);
ioc->chain_lookup = NULL;
}
@@ -3448,23 +3443,23 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->name);
goto out;
}
-   ioc->reply_post_free_dma_pool = pci_pool_create("reply_post_free pool",
-   ioc->pdev, sz, 16, 0);
+   ioc->reply_post_free_dma_pool = dma_pool_create("reply_post_free pool",
+   >pdev->dev, sz, 16, 0);
if (!ioc->reply_post_free_dma_pool) {
pr_err(MPT3SAS_FMT
-"reply_post_free pool: pci_pool_create failed\n",
+"reply_post_free pool: dma_pool_create failed\n",
 ioc->name);
goto out;
}
i = 0;
do {
ioc->reply_post[i].reply_post_free =
-   pci_pool_alloc(ioc->reply_post_free_dma_pool,
+   

[PATCH v6 13/15] scsi: mvsas: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mvsas/mv_init.c | 6 +++---
 drivers/scsi/mvsas/mv_sas.c  | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 8280046..41d2276 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -125,8 +125,7 @@ static void mvs_free(struct mvs_info *mvi)
else
slot_nr = MVS_CHIP_SLOT_SZ;
 
-   if (mvi->dma_pool)
-   pci_pool_destroy(mvi->dma_pool);
+   dma_pool_destroy(mvi->dma_pool);
 
if (mvi->tx)
dma_free_coherent(mvi->dev,
@@ -296,7 +295,8 @@ static int mvs_alloc(struct mvs_info *mvi, struct Scsi_Host 
*shost)
goto err_out;
 
sprintf(pool_name, "%s%d", "mvs_dma_pool", mvi->id);
-   mvi->dma_pool = pci_pool_create(pool_name, mvi->pdev, MVS_SLOT_BUF_SZ, 
16, 0);
+   mvi->dma_pool = dma_pool_create(pool_name, >pdev->dev,
+   MVS_SLOT_BUF_SZ, 16, 0);
if (!mvi->dma_pool) {
printk(KERN_DEBUG "failed to create dma pool %s.\n", 
pool_name);
goto err_out;
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index c7cc803..ee81d10 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -790,7 +790,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
slot->n_elem = n_elem;
slot->slot_tag = tag;
 
-   slot->buf = pci_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
+   slot->buf = dma_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
if (!slot->buf) {
rc = -ENOMEM;
goto err_out_tag;
@@ -840,7 +840,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
return rc;
 
 err_out_slot_buf:
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
 err_out_tag:
mvs_tag_free(mvi, tag);
 err_out:
@@ -918,7 +918,7 @@ static void mvs_slot_task_free(struct mvs_info *mvi, struct 
sas_task *task,
}
 
if (slot->buf) {
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
slot->buf = NULL;
}
list_del_init(>entry);
-- 
2.9.3



[PATCH v6 12/15] scsi: mpt3sas: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 73 +
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 5b7aec5..5ae1c23 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3200,9 +3200,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->sense) {
-   pci_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
-   if (ioc->sense_dma_pool)
-   pci_pool_destroy(ioc->sense_dma_pool);
+   dma_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
+   dma_pool_destroy(ioc->sense_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"sense_pool(0x%p): free\n",
ioc->name, ioc->sense));
@@ -3210,9 +3209,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply) {
-   pci_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
-   if (ioc->reply_dma_pool)
-   pci_pool_destroy(ioc->reply_dma_pool);
+   dma_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
+   dma_pool_destroy(ioc->reply_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_pool(0x%p): free\n",
ioc->name, ioc->reply));
@@ -3220,10 +3218,9 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply_free) {
-   pci_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
+   dma_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
ioc->reply_free_dma);
-   if (ioc->reply_free_dma_pool)
-   pci_pool_destroy(ioc->reply_free_dma_pool);
+   dma_pool_destroy(ioc->reply_free_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_free_pool(0x%p): free\n",
ioc->name, ioc->reply_free));
@@ -3234,7 +3231,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
do {
rps = >reply_post[i];
if (rps->reply_post_free) {
-   pci_pool_free(
+   dma_pool_free(
ioc->reply_post_free_dma_pool,
rps->reply_post_free,
rps->reply_post_free_dma);
@@ -3246,8 +3243,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
} while (ioc->rdpq_array_enable &&
   (++i < ioc->reply_queue_count));
 
-   if (ioc->reply_post_free_dma_pool)
-   pci_pool_destroy(ioc->reply_post_free_dma_pool);
+   dma_pool_destroy(ioc->reply_post_free_dma_pool);
kfree(ioc->reply_post);
}
 
@@ -3268,12 +3264,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
if (ioc->chain_lookup) {
for (i = 0; i < ioc->chain_depth; i++) {
if (ioc->chain_lookup[i].chain_buffer)
-   pci_pool_free(ioc->chain_dma_pool,
+   dma_pool_free(ioc->chain_dma_pool,
ioc->chain_lookup[i].chain_buffer,
ioc->chain_lookup[i].chain_buffer_dma);
}
-   if (ioc->chain_dma_pool)
-   pci_pool_destroy(ioc->chain_dma_pool);
+   dma_pool_destroy(ioc->chain_dma_pool);
free_pages((ulong)ioc->chain_lookup, ioc->chain_pages);
ioc->chain_lookup = NULL;
}
@@ -3448,23 +3443,23 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->name);
goto out;
}
-   ioc->reply_post_free_dma_pool = pci_pool_create("reply_post_free pool",
-   ioc->pdev, sz, 16, 0);
+   ioc->reply_post_free_dma_pool = dma_pool_create("reply_post_free pool",
+   >pdev->dev, sz, 16, 0);
if (!ioc->reply_post_free_dma_pool) {
pr_err(MPT3SAS_FMT
-"reply_post_free pool: pci_pool_create failed\n",
+"reply_post_free pool: dma_pool_create failed\n",
 ioc->name);
goto out;
}
i = 0;
do {
ioc->reply_post[i].reply_post_free =
-   pci_pool_alloc(ioc->reply_post_free_dma_pool,
+   dma_pool_alloc(ioc->reply_post_free_dma_pool,
GFP_KERNEL,
 

[PATCH v6 08/15] scsi: be2iscsi: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/scsi/be2iscsi/be_iscsi.c | 6 +++---
 drivers/scsi/be2iscsi/be_main.c  | 6 +++---
 drivers/scsi/be2iscsi/be_main.h  | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index a484457..d76ef77 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -87,8 +87,8 @@ struct iscsi_cls_session *beiscsi_session_create(struct 
iscsi_endpoint *ep,
return NULL;
sess = cls_session->dd_data;
beiscsi_sess = sess->dd_data;
-   beiscsi_sess->bhs_pool =  pci_pool_create("beiscsi_bhs_pool",
-  phba->pcidev,
+   beiscsi_sess->bhs_pool =  dma_pool_create("beiscsi_bhs_pool",
+  >pcidev->dev,
   sizeof(struct be_cmd_bhs),
   64, 0);
if (!beiscsi_sess->bhs_pool)
@@ -113,7 +113,7 @@ void beiscsi_session_destroy(struct iscsi_cls_session 
*cls_session)
struct beiscsi_session *beiscsi_sess = sess->dd_data;
 
printk(KERN_INFO "In beiscsi_session_destroy\n");
-   pci_pool_destroy(beiscsi_sess->bhs_pool);
+   dma_pool_destroy(beiscsi_sess->bhs_pool);
iscsi_session_teardown(cls_session);
 }
 
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 32b2713..dd43480 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -4307,7 +4307,7 @@ static void beiscsi_cleanup_task(struct iscsi_task *task)
pwrb_context = _ctrlr->wrb_context[cri_index];
 
if (io_task->cmd_bhs) {
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
task->hdr = NULL;
@@ -4424,7 +4424,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
struct beiscsi_session *beiscsi_sess = beiscsi_conn->beiscsi_sess;
dma_addr_t paddr;
 
-   io_task->cmd_bhs = pci_pool_alloc(beiscsi_sess->bhs_pool,
+   io_task->cmd_bhs = dma_pool_alloc(beiscsi_sess->bhs_pool,
  GFP_ATOMIC, );
if (!io_task->cmd_bhs)
return -ENOMEM;
@@ -4551,7 +4551,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
if (io_task->pwrb_handle)
free_wrb_handle(phba, pwrb_context, io_task->pwrb_handle);
io_task->pwrb_handle = NULL;
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
return -ENOMEM;
diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h
index 2188579..cf58d31 100644
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -446,7 +446,7 @@ struct beiscsi_hba {
 test_bit(BEISCSI_HBA_ONLINE, >state))
 
 struct beiscsi_session {
-   struct pci_pool *bhs_pool;
+   struct dma_pool *bhs_pool;
 };
 
 /**
-- 
2.9.3



[PATCH v6 02/15] dmaengine: pch_dma: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/dma/pch_dma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index f9028e9..afd8f27 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -123,7 +123,7 @@ struct pch_dma_chan {
 struct pch_dma {
struct dma_device   dma;
void __iomem *membase;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
struct pch_dma_regs regs;
struct pch_dma_desc_regs ch_regs[MAX_CHAN_NR];
struct pch_dma_chan channels[MAX_CHAN_NR];
@@ -437,7 +437,7 @@ static struct pch_dma_desc *pdc_alloc_desc(struct dma_chan 
*chan, gfp_t flags)
struct pch_dma *pd = to_pd(chan->device);
dma_addr_t addr;
 
-   desc = pci_pool_zalloc(pd->pool, flags, );
+   desc = dma_pool_zalloc(pd->pool, flags, );
if (desc) {
INIT_LIST_HEAD(>tx_list);
dma_async_tx_descriptor_init(>txd, chan);
@@ -549,7 +549,7 @@ static void pd_free_chan_resources(struct dma_chan *chan)
spin_unlock_irq(_chan->lock);
 
list_for_each_entry_safe(desc, _d, _list, desc_node)
-   pci_pool_free(pd->pool, desc, desc->txd.phys);
+   dma_pool_free(pd->pool, desc, desc->txd.phys);
 
pdc_enable_irq(chan, 0);
 }
@@ -880,7 +880,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
goto err_iounmap;
}
 
-   pd->pool = pci_pool_create("pch_dma_desc_pool", pdev,
+   pd->pool = dma_pool_create("pch_dma_desc_pool", >dev,
   sizeof(struct pch_dma_desc), 4, 0);
if (!pd->pool) {
dev_err(>dev, "Failed to alloc DMA descriptors\n");
@@ -931,7 +931,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
return 0;
 
 err_free_pool:
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
 err_free_irq:
free_irq(pdev->irq, pd);
 err_iounmap:
@@ -963,7 +963,7 @@ static void pch_dma_remove(struct pci_dev *pdev)
tasklet_kill(_chan->tasklet);
}
 
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
pci_iounmap(pdev, pd->membase);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3



[PATCH v6 08/15] scsi: be2iscsi: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/scsi/be2iscsi/be_iscsi.c | 6 +++---
 drivers/scsi/be2iscsi/be_main.c  | 6 +++---
 drivers/scsi/be2iscsi/be_main.h  | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index a484457..d76ef77 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -87,8 +87,8 @@ struct iscsi_cls_session *beiscsi_session_create(struct 
iscsi_endpoint *ep,
return NULL;
sess = cls_session->dd_data;
beiscsi_sess = sess->dd_data;
-   beiscsi_sess->bhs_pool =  pci_pool_create("beiscsi_bhs_pool",
-  phba->pcidev,
+   beiscsi_sess->bhs_pool =  dma_pool_create("beiscsi_bhs_pool",
+  >pcidev->dev,
   sizeof(struct be_cmd_bhs),
   64, 0);
if (!beiscsi_sess->bhs_pool)
@@ -113,7 +113,7 @@ void beiscsi_session_destroy(struct iscsi_cls_session 
*cls_session)
struct beiscsi_session *beiscsi_sess = sess->dd_data;
 
printk(KERN_INFO "In beiscsi_session_destroy\n");
-   pci_pool_destroy(beiscsi_sess->bhs_pool);
+   dma_pool_destroy(beiscsi_sess->bhs_pool);
iscsi_session_teardown(cls_session);
 }
 
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 32b2713..dd43480 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -4307,7 +4307,7 @@ static void beiscsi_cleanup_task(struct iscsi_task *task)
pwrb_context = _ctrlr->wrb_context[cri_index];
 
if (io_task->cmd_bhs) {
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
task->hdr = NULL;
@@ -4424,7 +4424,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
struct beiscsi_session *beiscsi_sess = beiscsi_conn->beiscsi_sess;
dma_addr_t paddr;
 
-   io_task->cmd_bhs = pci_pool_alloc(beiscsi_sess->bhs_pool,
+   io_task->cmd_bhs = dma_pool_alloc(beiscsi_sess->bhs_pool,
  GFP_ATOMIC, );
if (!io_task->cmd_bhs)
return -ENOMEM;
@@ -4551,7 +4551,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
if (io_task->pwrb_handle)
free_wrb_handle(phba, pwrb_context, io_task->pwrb_handle);
io_task->pwrb_handle = NULL;
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
return -ENOMEM;
diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h
index 2188579..cf58d31 100644
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -446,7 +446,7 @@ struct beiscsi_hba {
 test_bit(BEISCSI_HBA_ONLINE, >state))
 
 struct beiscsi_session {
-   struct pci_pool *bhs_pool;
+   struct dma_pool *bhs_pool;
 };
 
 /**
-- 
2.9.3



[PATCH v6 02/15] dmaengine: pch_dma: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/dma/pch_dma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index f9028e9..afd8f27 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -123,7 +123,7 @@ struct pch_dma_chan {
 struct pch_dma {
struct dma_device   dma;
void __iomem *membase;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
struct pch_dma_regs regs;
struct pch_dma_desc_regs ch_regs[MAX_CHAN_NR];
struct pch_dma_chan channels[MAX_CHAN_NR];
@@ -437,7 +437,7 @@ static struct pch_dma_desc *pdc_alloc_desc(struct dma_chan 
*chan, gfp_t flags)
struct pch_dma *pd = to_pd(chan->device);
dma_addr_t addr;
 
-   desc = pci_pool_zalloc(pd->pool, flags, );
+   desc = dma_pool_zalloc(pd->pool, flags, );
if (desc) {
INIT_LIST_HEAD(>tx_list);
dma_async_tx_descriptor_init(>txd, chan);
@@ -549,7 +549,7 @@ static void pd_free_chan_resources(struct dma_chan *chan)
spin_unlock_irq(_chan->lock);
 
list_for_each_entry_safe(desc, _d, _list, desc_node)
-   pci_pool_free(pd->pool, desc, desc->txd.phys);
+   dma_pool_free(pd->pool, desc, desc->txd.phys);
 
pdc_enable_irq(chan, 0);
 }
@@ -880,7 +880,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
goto err_iounmap;
}
 
-   pd->pool = pci_pool_create("pch_dma_desc_pool", pdev,
+   pd->pool = dma_pool_create("pch_dma_desc_pool", >dev,
   sizeof(struct pch_dma_desc), 4, 0);
if (!pd->pool) {
dev_err(>dev, "Failed to alloc DMA descriptors\n");
@@ -931,7 +931,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
return 0;
 
 err_free_pool:
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
 err_free_irq:
free_irq(pdev->irq, pd);
 err_iounmap:
@@ -963,7 +963,7 @@ static void pch_dma_remove(struct pci_dev *pdev)
tasklet_kill(_chan->tasklet);
}
 
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
pci_iounmap(pdev, pd->membase);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3



[PATCH v6 01/15] block: DAC960: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/block/DAC960.c | 38 ++
 drivers/block/DAC960.h |  4 ++--
 2 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
index 26a51be..a0883ad 100644
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -268,17 +268,17 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
   void *AllocationPointer = NULL;
   void *ScatterGatherCPU = NULL;
   dma_addr_t ScatterGatherDMA;
-  struct pci_pool *ScatterGatherPool;
+  struct dma_pool *ScatterGatherPool;
   void *RequestSenseCPU = NULL;
   dma_addr_t RequestSenseDMA;
-  struct pci_pool *RequestSensePool = NULL;
+  struct dma_pool *RequestSensePool = NULL;
 
   if (Controller->FirmwareType == DAC960_V1_Controller)
 {
   CommandAllocationLength = offsetof(DAC960_Command_T, V1.EndMarker);
   CommandAllocationGroupSize = DAC960_V1_CommandAllocationGroupSize;
-  ScatterGatherPool = pci_pool_create("DAC960_V1_ScatterGather",
-   Controller->PCIDevice,
+  ScatterGatherPool = dma_pool_create("DAC960_V1_ScatterGather",
+   >PCIDevice->dev,
DAC960_V1_ScatterGatherLimit * sizeof(DAC960_V1_ScatterGatherSegment_T),
sizeof(DAC960_V1_ScatterGatherSegment_T), 0);
   if (ScatterGatherPool == NULL)
@@ -290,18 +290,18 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
 {
   CommandAllocationLength = offsetof(DAC960_Command_T, V2.EndMarker);
   CommandAllocationGroupSize = DAC960_V2_CommandAllocationGroupSize;
-  ScatterGatherPool = pci_pool_create("DAC960_V2_ScatterGather",
-   Controller->PCIDevice,
+  ScatterGatherPool = dma_pool_create("DAC960_V2_ScatterGather",
+   >PCIDevice->dev,
DAC960_V2_ScatterGatherLimit * sizeof(DAC960_V2_ScatterGatherSegment_T),
sizeof(DAC960_V2_ScatterGatherSegment_T), 0);
   if (ScatterGatherPool == NULL)
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION (SG)");
-  RequestSensePool = pci_pool_create("DAC960_V2_RequestSense",
-   Controller->PCIDevice, sizeof(DAC960_SCSI_RequestSense_T),
+  RequestSensePool = dma_pool_create("DAC960_V2_RequestSense",
+   >PCIDevice->dev, sizeof(DAC960_SCSI_RequestSense_T),
sizeof(int), 0);
   if (RequestSensePool == NULL) {
-   pci_pool_destroy(ScatterGatherPool);
+   dma_pool_destroy(ScatterGatherPool);
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION (SG)");
   }
@@ -335,16 +335,16 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
   Command->Next = Controller->FreeCommands;
   Controller->FreeCommands = Command;
   Controller->Commands[CommandIdentifier-1] = Command;
-  ScatterGatherCPU = pci_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
+  ScatterGatherCPU = dma_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
);
   if (ScatterGatherCPU == NULL)
  return DAC960_Failure(Controller, "AUXILIARY STRUCTURE CREATION");
 
   if (RequestSensePool != NULL) {
- RequestSenseCPU = pci_pool_alloc(RequestSensePool, GFP_ATOMIC,
+ RequestSenseCPU = dma_pool_alloc(RequestSensePool, GFP_ATOMIC,
);
  if (RequestSenseCPU == NULL) {
-pci_pool_free(ScatterGatherPool, ScatterGatherCPU,
+dma_pool_free(ScatterGatherPool, ScatterGatherCPU,
 ScatterGatherDMA);
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION");
@@ -379,8 +379,8 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
 static void DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T *Controller)
 {
   int i;
-  struct pci_pool *ScatterGatherPool = Controller->ScatterGatherPool;
-  struct pci_pool *RequestSensePool = NULL;
+  struct dma_pool *ScatterGatherPool = Controller->ScatterGatherPool;
+  struct dma_pool *RequestSensePool = NULL;
   void *ScatterGatherCPU;
   dma_addr_t ScatterGatherDMA;
   void *RequestSenseCPU;
@@ -411,9 +411,9 @@ static void 
DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T *Controller)
  RequestSenseDMA = Command->V2.RequestSenseDMA;
   }
   if (ScatterGatherCPU != NULL)
-  pci_pool_free(ScatterGatherPool, ScatterGatherCPU, ScatterGatherDMA);
+  dma_pool_free(ScatterGatherPool, ScatterGatherCPU, ScatterGatherDMA);
  

[PATCH v6 01/15] block: DAC960: Replace PCI pool old API

2017-03-19 Thread Romain Perier
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/block/DAC960.c | 38 ++
 drivers/block/DAC960.h |  4 ++--
 2 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
index 26a51be..a0883ad 100644
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -268,17 +268,17 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
   void *AllocationPointer = NULL;
   void *ScatterGatherCPU = NULL;
   dma_addr_t ScatterGatherDMA;
-  struct pci_pool *ScatterGatherPool;
+  struct dma_pool *ScatterGatherPool;
   void *RequestSenseCPU = NULL;
   dma_addr_t RequestSenseDMA;
-  struct pci_pool *RequestSensePool = NULL;
+  struct dma_pool *RequestSensePool = NULL;
 
   if (Controller->FirmwareType == DAC960_V1_Controller)
 {
   CommandAllocationLength = offsetof(DAC960_Command_T, V1.EndMarker);
   CommandAllocationGroupSize = DAC960_V1_CommandAllocationGroupSize;
-  ScatterGatherPool = pci_pool_create("DAC960_V1_ScatterGather",
-   Controller->PCIDevice,
+  ScatterGatherPool = dma_pool_create("DAC960_V1_ScatterGather",
+   >PCIDevice->dev,
DAC960_V1_ScatterGatherLimit * sizeof(DAC960_V1_ScatterGatherSegment_T),
sizeof(DAC960_V1_ScatterGatherSegment_T), 0);
   if (ScatterGatherPool == NULL)
@@ -290,18 +290,18 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
 {
   CommandAllocationLength = offsetof(DAC960_Command_T, V2.EndMarker);
   CommandAllocationGroupSize = DAC960_V2_CommandAllocationGroupSize;
-  ScatterGatherPool = pci_pool_create("DAC960_V2_ScatterGather",
-   Controller->PCIDevice,
+  ScatterGatherPool = dma_pool_create("DAC960_V2_ScatterGather",
+   >PCIDevice->dev,
DAC960_V2_ScatterGatherLimit * sizeof(DAC960_V2_ScatterGatherSegment_T),
sizeof(DAC960_V2_ScatterGatherSegment_T), 0);
   if (ScatterGatherPool == NULL)
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION (SG)");
-  RequestSensePool = pci_pool_create("DAC960_V2_RequestSense",
-   Controller->PCIDevice, sizeof(DAC960_SCSI_RequestSense_T),
+  RequestSensePool = dma_pool_create("DAC960_V2_RequestSense",
+   >PCIDevice->dev, sizeof(DAC960_SCSI_RequestSense_T),
sizeof(int), 0);
   if (RequestSensePool == NULL) {
-   pci_pool_destroy(ScatterGatherPool);
+   dma_pool_destroy(ScatterGatherPool);
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION (SG)");
   }
@@ -335,16 +335,16 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
   Command->Next = Controller->FreeCommands;
   Controller->FreeCommands = Command;
   Controller->Commands[CommandIdentifier-1] = Command;
-  ScatterGatherCPU = pci_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
+  ScatterGatherCPU = dma_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
);
   if (ScatterGatherCPU == NULL)
  return DAC960_Failure(Controller, "AUXILIARY STRUCTURE CREATION");
 
   if (RequestSensePool != NULL) {
- RequestSenseCPU = pci_pool_alloc(RequestSensePool, GFP_ATOMIC,
+ RequestSenseCPU = dma_pool_alloc(RequestSensePool, GFP_ATOMIC,
);
  if (RequestSenseCPU == NULL) {
-pci_pool_free(ScatterGatherPool, ScatterGatherCPU,
+dma_pool_free(ScatterGatherPool, ScatterGatherCPU,
 ScatterGatherDMA);
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION");
@@ -379,8 +379,8 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
 static void DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T *Controller)
 {
   int i;
-  struct pci_pool *ScatterGatherPool = Controller->ScatterGatherPool;
-  struct pci_pool *RequestSensePool = NULL;
+  struct dma_pool *ScatterGatherPool = Controller->ScatterGatherPool;
+  struct dma_pool *RequestSensePool = NULL;
   void *ScatterGatherCPU;
   dma_addr_t ScatterGatherDMA;
   void *RequestSenseCPU;
@@ -411,9 +411,9 @@ static void 
DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T *Controller)
  RequestSenseDMA = Command->V2.RequestSenseDMA;
   }
   if (ScatterGatherCPU != NULL)
-  pci_pool_free(ScatterGatherPool, ScatterGatherCPU, ScatterGatherDMA);
+  dma_pool_free(ScatterGatherPool, ScatterGatherCPU, ScatterGatherDMA);
   if (RequestSenseCPU != NULL)
-  pci_pool_free(RequestSensePool, 

Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

2017-03-19 Thread Arkady
Nicolai,

Regarding the debugfs_create_file() which ignores .mmap field in the
struct file_operations. The patch is a part of the kernel 4.8 in the
Ubuntu 16.10 and breaks quite a few online code examples of mmap
drivers.

Is is acceptable to replace the debugfs_create_file() by a macro and
fail the compilation if the .mmap field is not initialized.
Alternatively debugfs_create_file() can return an error if .mmap is
not NULL.

Thank you, Arkady.


Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data

2017-03-19 Thread Arkady
Nicolai,

Regarding the debugfs_create_file() which ignores .mmap field in the
struct file_operations. The patch is a part of the kernel 4.8 in the
Ubuntu 16.10 and breaks quite a few online code examples of mmap
drivers.

Is is acceptable to replace the debugfs_create_file() by a macro and
fail the compilation if the .mmap field is not initialized.
Alternatively debugfs_create_file() can return an error if .mmap is
not NULL.

Thank you, Arkady.


Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-19 Thread Mauro Carvalho Chehab
Em Fri, 17 Mar 2017 17:34:36 -0700
Eric Anholt  escreveu:

> Mauro Carvalho Chehab  writes:
> 
> > Em Wed, 15 Mar 2017 18:46:24 -0700
> > Michael Zoran  escreveu:
> >
> >> On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:
> >> 
> >> > No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
> >> > Perhaps I'm missing some other patch. I'm compiling it from
> >> > the Greg's staging tree (branch staging-next):
> >> >  https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.
> >> > git/log/?h=staging-next
> >> > 
> >> > Btw, as I'm running Raspbian, and didn't want to use compat32 bits, 
> >> > I'm compiling the Kernel as an arm32 bits Kernel.
> >> > 
> >> > I did a small trick to build the DTB on arm32:
> >> > 
> >> >  ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
> >> > arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> >> >  ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
> >> > arch/arm/boot/dts/bcm2837.dtsi
> >> >  git checkout arch/arm/boot/dts/Makefile
> >> >  sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb bcm2837-rpi-3-
> >> > b.dtb," a && mv a arch/arm/boot/dts/Makefile
> >> >   
> >> 
> >> Two other hacks are currently needed to get the camera to work:
> >> 
> >> 1. Add this to config.txt(This required to get the firmware to detect
> >> the camera)
> >> 
> >> start_x=1
> >> gpu_mem=128
> >
> > I had this already.
> >
> >> 
> >> 2. VC4 is incompatible with the firmware at this time, so you need 
> >> to presently munge the build configuration. What you do is leave
> >> simplefb in the build config(I'm assuming you already have that), but
> >> you will need to remove VC4 from the config.
> >> 
> >> The firmware currently adds a node for a simplefb for debugging
> >> purposes to show the boot log.  Surprisingly, this is still good enough
> >> for basic usage and testing.  
> >
> > That solved the issue. Thanks! It would be good to add a notice
> > about that at the TODO, not let it build if DRM_VC4.
> >
> > Please consider applying the enclosed path.
> 
> The VC4 incompatibility (camera firmware's AWB ends up briefly using the
> GPU, without coordinating with the Linux driver) is supposed to be fixed
> in current firmware
> (https://github.com/raspberrypi/firmware/issues/760#issuecomment-287391025)

With the current firmware, when X starts, the screen becomes blank,
with upstream Kernel (it works with the downstream Kernel shipped with 
the firmware).

Maybe something changed at DT?

Thanks,
Mauro


Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

2017-03-19 Thread Mauro Carvalho Chehab
Em Fri, 17 Mar 2017 17:34:36 -0700
Eric Anholt  escreveu:

> Mauro Carvalho Chehab  writes:
> 
> > Em Wed, 15 Mar 2017 18:46:24 -0700
> > Michael Zoran  escreveu:
> >
> >> On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:
> >> 
> >> > No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
> >> > Perhaps I'm missing some other patch. I'm compiling it from
> >> > the Greg's staging tree (branch staging-next):
> >> >  https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.
> >> > git/log/?h=staging-next
> >> > 
> >> > Btw, as I'm running Raspbian, and didn't want to use compat32 bits, 
> >> > I'm compiling the Kernel as an arm32 bits Kernel.
> >> > 
> >> > I did a small trick to build the DTB on arm32:
> >> > 
> >> >  ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
> >> > arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> >> >  ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
> >> > arch/arm/boot/dts/bcm2837.dtsi
> >> >  git checkout arch/arm/boot/dts/Makefile
> >> >  sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb bcm2837-rpi-3-
> >> > b.dtb," a && mv a arch/arm/boot/dts/Makefile
> >> >   
> >> 
> >> Two other hacks are currently needed to get the camera to work:
> >> 
> >> 1. Add this to config.txt(This required to get the firmware to detect
> >> the camera)
> >> 
> >> start_x=1
> >> gpu_mem=128
> >
> > I had this already.
> >
> >> 
> >> 2. VC4 is incompatible with the firmware at this time, so you need 
> >> to presently munge the build configuration. What you do is leave
> >> simplefb in the build config(I'm assuming you already have that), but
> >> you will need to remove VC4 from the config.
> >> 
> >> The firmware currently adds a node for a simplefb for debugging
> >> purposes to show the boot log.  Surprisingly, this is still good enough
> >> for basic usage and testing.  
> >
> > That solved the issue. Thanks! It would be good to add a notice
> > about that at the TODO, not let it build if DRM_VC4.
> >
> > Please consider applying the enclosed path.
> 
> The VC4 incompatibility (camera firmware's AWB ends up briefly using the
> GPU, without coordinating with the Linux driver) is supposed to be fixed
> in current firmware
> (https://github.com/raspberrypi/firmware/issues/760#issuecomment-287391025)

With the current firmware, when X starts, the screen becomes blank,
with upstream Kernel (it works with the downstream Kernel shipped with 
the firmware).

Maybe something changed at DT?

Thanks,
Mauro


Re: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

2017-03-19 Thread Thomas Garnier
On Sun, Mar 19, 2017 at 9:03 AM, Wei Yang  wrote:
> On Fri, Mar 17, 2017 at 10:50:34AM -0700, Thomas Garnier wrote:
>>This patch remove fixmap header usage on non-x86 code that was
>>introduced by the adaptable MODULE_END change.
>
> Hi, Thomas
>
> In this patch, it looks you are trying to do two things for my understanding:
> 1. To include  in asm/pagetable_64.h and remove the include in
> some of the x86 files
> 2. Remove  in mm/vmalloc.c
>
> I think your change log covers the second task in the patch, but not not talk
> about the first task you did in the patch. If you could mention it in commit
> log, it would be good for maintain.

I agree, I am not the best at writing commits (by far). What's the
best way for me to correct that? (the bot seem to have taken it).

>
> BTW, I have little knowledge about MODULE_END. By searching the code
> MODULE_END is not used in arch/x86. If you would like to mention the commit
> which introduce the problem, it would be more helpful to review the code.

It is used in many places in arch/x86, kasan, head64, fault etc..:
http://lxr.free-electrons.com/ident?i=MODULES_END

>
>>
>>Signed-off-by: Thomas Garnier 
>>---
>>Based on tip:x86/mm
>>---
>> arch/x86/include/asm/pgtable_64.h | 1 +
>> arch/x86/kernel/module.c  | 1 -
>> arch/x86/mm/dump_pagetables.c | 1 -
>> arch/x86/mm/kasan_init_64.c   | 1 -
>> mm/vmalloc.c  | 4 
>> 5 files changed, 1 insertion(+), 7 deletions(-)
>>
>>diff --git a/arch/x86/include/asm/pgtable_64.h 
>>b/arch/x86/include/asm/pgtable_64.h
>>index 73c7ccc38912..67608d4abc2c 100644
>>--- a/arch/x86/include/asm/pgtable_64.h
>>+++ b/arch/x86/include/asm/pgtable_64.h
>>@@ -13,6 +13,7 @@
>> #include 
>> #include 
>> #include 
>>+#include 
>>
>
> Hmm... I see in both pgtable_32.h and pgtable_64.h will include 
> after this change. And pgtable_32.h and pgtable_64.h will be included only in
> pgtable.h. So is it possible to include  in pgtable.h for once
> instead of include it in both files? Any concerns you would have?

I am not sure I understood. Only 64-bit need this header to correctly
get MODULES_END, that's why I added it to pgtable_64.h only. I tried
to add it lower before and ran into multiple header errors.

>
>> extern pud_t level3_kernel_pgt[512];
>> extern pud_t level3_ident_pgt[512];
>>diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
>>index fad61caac75e..477ae806c2fa 100644
>>--- a/arch/x86/kernel/module.c
>>+++ b/arch/x86/kernel/module.c
>>@@ -35,7 +35,6 @@
>> #include 
>> #include 
>> #include 
>>-#include 
>>
>> #if 0
>> #define DEBUGP(fmt, ...)  \
>>diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
>>index 75efeecc85eb..58b5bee7ea27 100644
>>--- a/arch/x86/mm/dump_pagetables.c
>>+++ b/arch/x86/mm/dump_pagetables.c
>>@@ -20,7 +20,6 @@
>>
>> #include 
>> #include 
>>-#include 
>>
>> /*
>>  * The dumper groups pagetable entries of the same type into one, and for
>>diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
>>index 1bde19ef86bd..8d63d7a104c3 100644
>>--- a/arch/x86/mm/kasan_init_64.c
>>+++ b/arch/x86/mm/kasan_init_64.c
>>@@ -9,7 +9,6 @@
>>
>> #include 
>> #include 
>>-#include 
>>
>> extern pgd_t early_level4_pgt[PTRS_PER_PGD];
>> extern struct range pfn_mapped[E820_X_MAX];
>>diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>>index b7d2a23349f4..0dd80222b20b 100644
>>--- a/mm/vmalloc.c
>>+++ b/mm/vmalloc.c
>>@@ -36,10 +36,6 @@
>> #include 
>> #include 
>>
>>-#ifdef CONFIG_X86
>>-# include 
>>-#endif
>>-
>> #include "internal.h"
>>
>> struct vfree_deferred {
>>--
>>2.12.0.367.g23dc2f6d3c-goog
>
> --
> Wei Yang
> Help you, Help me



-- 
Thomas


Re: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

2017-03-19 Thread Thomas Garnier
On Sun, Mar 19, 2017 at 9:03 AM, Wei Yang  wrote:
> On Fri, Mar 17, 2017 at 10:50:34AM -0700, Thomas Garnier wrote:
>>This patch remove fixmap header usage on non-x86 code that was
>>introduced by the adaptable MODULE_END change.
>
> Hi, Thomas
>
> In this patch, it looks you are trying to do two things for my understanding:
> 1. To include  in asm/pagetable_64.h and remove the include in
> some of the x86 files
> 2. Remove  in mm/vmalloc.c
>
> I think your change log covers the second task in the patch, but not not talk
> about the first task you did in the patch. If you could mention it in commit
> log, it would be good for maintain.

I agree, I am not the best at writing commits (by far). What's the
best way for me to correct that? (the bot seem to have taken it).

>
> BTW, I have little knowledge about MODULE_END. By searching the code
> MODULE_END is not used in arch/x86. If you would like to mention the commit
> which introduce the problem, it would be more helpful to review the code.

It is used in many places in arch/x86, kasan, head64, fault etc..:
http://lxr.free-electrons.com/ident?i=MODULES_END

>
>>
>>Signed-off-by: Thomas Garnier 
>>---
>>Based on tip:x86/mm
>>---
>> arch/x86/include/asm/pgtable_64.h | 1 +
>> arch/x86/kernel/module.c  | 1 -
>> arch/x86/mm/dump_pagetables.c | 1 -
>> arch/x86/mm/kasan_init_64.c   | 1 -
>> mm/vmalloc.c  | 4 
>> 5 files changed, 1 insertion(+), 7 deletions(-)
>>
>>diff --git a/arch/x86/include/asm/pgtable_64.h 
>>b/arch/x86/include/asm/pgtable_64.h
>>index 73c7ccc38912..67608d4abc2c 100644
>>--- a/arch/x86/include/asm/pgtable_64.h
>>+++ b/arch/x86/include/asm/pgtable_64.h
>>@@ -13,6 +13,7 @@
>> #include 
>> #include 
>> #include 
>>+#include 
>>
>
> Hmm... I see in both pgtable_32.h and pgtable_64.h will include 
> after this change. And pgtable_32.h and pgtable_64.h will be included only in
> pgtable.h. So is it possible to include  in pgtable.h for once
> instead of include it in both files? Any concerns you would have?

I am not sure I understood. Only 64-bit need this header to correctly
get MODULES_END, that's why I added it to pgtable_64.h only. I tried
to add it lower before and ran into multiple header errors.

>
>> extern pud_t level3_kernel_pgt[512];
>> extern pud_t level3_ident_pgt[512];
>>diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
>>index fad61caac75e..477ae806c2fa 100644
>>--- a/arch/x86/kernel/module.c
>>+++ b/arch/x86/kernel/module.c
>>@@ -35,7 +35,6 @@
>> #include 
>> #include 
>> #include 
>>-#include 
>>
>> #if 0
>> #define DEBUGP(fmt, ...)  \
>>diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
>>index 75efeecc85eb..58b5bee7ea27 100644
>>--- a/arch/x86/mm/dump_pagetables.c
>>+++ b/arch/x86/mm/dump_pagetables.c
>>@@ -20,7 +20,6 @@
>>
>> #include 
>> #include 
>>-#include 
>>
>> /*
>>  * The dumper groups pagetable entries of the same type into one, and for
>>diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
>>index 1bde19ef86bd..8d63d7a104c3 100644
>>--- a/arch/x86/mm/kasan_init_64.c
>>+++ b/arch/x86/mm/kasan_init_64.c
>>@@ -9,7 +9,6 @@
>>
>> #include 
>> #include 
>>-#include 
>>
>> extern pgd_t early_level4_pgt[PTRS_PER_PGD];
>> extern struct range pfn_mapped[E820_X_MAX];
>>diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>>index b7d2a23349f4..0dd80222b20b 100644
>>--- a/mm/vmalloc.c
>>+++ b/mm/vmalloc.c
>>@@ -36,10 +36,6 @@
>> #include 
>> #include 
>>
>>-#ifdef CONFIG_X86
>>-# include 
>>-#endif
>>-
>> #include "internal.h"
>>
>> struct vfree_deferred {
>>--
>>2.12.0.367.g23dc2f6d3c-goog
>
> --
> Wei Yang
> Help you, Help me



-- 
Thomas


Re: [PATCH v4 00/13] mm: sub-section memory hotplug support

2017-03-19 Thread Michal Hocko
On Thu 16-03-17 12:04:48, Dan Williams wrote:
> On Thu, Mar 16, 2017 at 10:48 AM, Michal Hocko  wrote:
> > Hi,
> > I didn't get to look through the patch series yet and I might not be
> > able before LSF/MM. How urgent is this? I am primarily asking because
> > the memory hotplug is really convoluted right now and putting more on
> > top doesn't really sound like the thing we really want. I have tried to
> > simplify the code [1] already but this is an early stage work so I do
> > not want to impose any burden on you. So I am wondering whether this
> > is something that needs to be merged very soon or it can wait for the
> > rework and hopefully end up being much simpler in the end as well.
> >
> > What do you think?
> 
> In general, I think it's better to add new features after
> reworks/cleanup, but it's not clear to me (yet) that the problem you
> are trying to solve makes this sub-section enabling for ZONE_DEVICE
> any simpler.
> 
> > [1] http://lkml.kernel.org/r/20170315091347.ga32...@dhcp22.suse.cz
> 
> ZONE_DEVICE pages are never "online". The patch says "Instead we do
> page->zone association from move_pfn_range which is called from
> online_pages." which means the new scheme currently doesn't comprehend
> the sprinkled ZONE_DEVICE hacks in the memory hotplug code.

I hope we can get rid of those...
 
> However, that said, I might take a look at whether the hacks belong in
> the auto-online code so that we can share the delayed zone
> initialization, but still skip marking the memory online per the
> expectations of ZONE_DEVICE.

I think this should be trivial. AFAIU it should be sufficient to split
my move_pfn_range into online_pfn_range which would do the MMOP_ONLINE*
handling and the real move_pfn_range which would do the zone specific
association. Your devm_memremap_pages would then call this
move_pfn_range after arch_add_memory. Or am I overlooking something?

I would still have to addapt your changes to remove hardcoded section
aligned expectations but that shouldn't be a big problem I guess. I
still haven't looked into those deeply to fully understand them.

> I expect it would be confusing to have
> memblock devices in sysfs for ranges that can't be marked online?

Well, if their only valid_zone would be ZONE_DEVICE then I believe it
shouldn't be confusing much.
-- 
Michal Hocko
SUSE Labs


Re: [PATCH v4 00/13] mm: sub-section memory hotplug support

2017-03-19 Thread Michal Hocko
On Thu 16-03-17 12:04:48, Dan Williams wrote:
> On Thu, Mar 16, 2017 at 10:48 AM, Michal Hocko  wrote:
> > Hi,
> > I didn't get to look through the patch series yet and I might not be
> > able before LSF/MM. How urgent is this? I am primarily asking because
> > the memory hotplug is really convoluted right now and putting more on
> > top doesn't really sound like the thing we really want. I have tried to
> > simplify the code [1] already but this is an early stage work so I do
> > not want to impose any burden on you. So I am wondering whether this
> > is something that needs to be merged very soon or it can wait for the
> > rework and hopefully end up being much simpler in the end as well.
> >
> > What do you think?
> 
> In general, I think it's better to add new features after
> reworks/cleanup, but it's not clear to me (yet) that the problem you
> are trying to solve makes this sub-section enabling for ZONE_DEVICE
> any simpler.
> 
> > [1] http://lkml.kernel.org/r/20170315091347.ga32...@dhcp22.suse.cz
> 
> ZONE_DEVICE pages are never "online". The patch says "Instead we do
> page->zone association from move_pfn_range which is called from
> online_pages." which means the new scheme currently doesn't comprehend
> the sprinkled ZONE_DEVICE hacks in the memory hotplug code.

I hope we can get rid of those...
 
> However, that said, I might take a look at whether the hacks belong in
> the auto-online code so that we can share the delayed zone
> initialization, but still skip marking the memory online per the
> expectations of ZONE_DEVICE.

I think this should be trivial. AFAIU it should be sufficient to split
my move_pfn_range into online_pfn_range which would do the MMOP_ONLINE*
handling and the real move_pfn_range which would do the zone specific
association. Your devm_memremap_pages would then call this
move_pfn_range after arch_add_memory. Or am I overlooking something?

I would still have to addapt your changes to remove hardcoded section
aligned expectations but that shouldn't be a big problem I guess. I
still haven't looked into those deeply to fully understand them.

> I expect it would be confusing to have
> memblock devices in sysfs for ranges that can't be marked online?

Well, if their only valid_zone would be ZONE_DEVICE then I believe it
shouldn't be confusing much.
-- 
Michal Hocko
SUSE Labs


Google Summer of Code: WireGuard & kernel hacking

2017-03-19 Thread Jason A. Donenfeld
Hey guys,

WireGuard is accepting students for Google Summer of Code. If you're a
student and want to spend the summer writing kernel networking code,
cryptography code, security code, and all sorts of interesting things,
this might be somewhat appealing to you. A few project ideas are
listed here: https://www.wireguard.io/gsoc/

If you know students or are a student, don't hesitate to reach out.

Thanks,
Jason


Google Summer of Code: WireGuard & kernel hacking

2017-03-19 Thread Jason A. Donenfeld
Hey guys,

WireGuard is accepting students for Google Summer of Code. If you're a
student and want to spend the summer writing kernel networking code,
cryptography code, security code, and all sorts of interesting things,
this might be somewhat appealing to you. A few project ideas are
listed here: https://www.wireguard.io/gsoc/

If you know students or are a student, don't hesitate to reach out.

Thanks,
Jason


Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-19 Thread Wolfgang Grandegger

Hello Akshay,

I still see some improvements...

Am 17.03.2017 um 22:10 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---

v3 -> v4:
Address comments from Wolfgang Grandegger:
- Add support for CAN warning state reporting
- Add support for reporting tx/rx error counts in bus error messages
- Keep bus error interrupts enabled to detect CAN state changes
- Fix bug in restart code after BUSOFF state
- Clean up error handling code

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1072 ++
 3 files changed, 1079 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
depends on SPI

+config CAN_HI311X
+   tristate "Holt HI311x SPI CAN controllers"
+   depends on CAN_DEV && SPI && HAS_DMA
+   ---help---
+ Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
tristate "Microchip MCP251x SPI CAN controllers"
depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)   += hi311x.o
 obj-$(CONFIG_CAN_MCP251X)  += mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..2a3d794
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1072 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program 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.
+ */


... snip...


+
+static irqreturn_t hi3110_can_ist(int irq, void *dev_id)
+{
+   struct hi3110_priv *priv = dev_id;
+   struct spi_device *spi = priv->spi;
+   struct net_device *net = priv->net;
+
+   mutex_lock(>hi3110_lock);
+
+   while (!priv->force_quit) {
+   enum can_state new_state;
+   u8 intf, eflag, statf;
+
+   while (!(HI3110_STAT_RXFMTY &
+  (statf = hi3110_read(spi, HI3110_READ_STATF {
+   hi3110_hw_rx(spi);
+   }
+
+   intf = hi3110_read(spi, HI3110_READ_INTF);


I think HI3110_READ_ERR is only valid if HI3110_INT_BUSERR is set! 
Therefore:


if ((intf & HI3110_INT_BUSERR) {

It saves reading one SPI register in the message processing path. Please 
check if back-to-error-active still comes.



+   eflag = hi3110_read(spi, HI3110_READ_ERR);
+   /* Update can state */
+   if (eflag & HI3110_ERR_BUSOFF)
+   new_state = CAN_STATE_BUS_OFF;
+   else if (eflag & HI3110_ERR_PASSIVE_MASK)
+   new_state = CAN_STATE_ERROR_PASSIVE;
+   else if (statf & HI3110_STAT_ERRW)
+   new_state = CAN_STATE_ERROR_WARNING;
+   else
+   new_state = CAN_STATE_ERROR_ACTIVE;
+
+   if (new_state != priv->can.state) {
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   enum can_state rx_state, tx_state;
+   u8 rxerr, txerr;
+
+   skb = alloc_can_err_skb(net, );
+   if (!skb)
+   break;
+
+   txerr = hi3110_read(spi, HI3110_READ_TEC);
+   rxerr = hi3110_read(spi, HI3110_READ_REC);
+   cf->data[6] = txerr;
+   cf->data[7] = rxerr;
+   tx_state = txerr >= rxerr ? new_state : 0;
+   rx_state = txerr <= rxerr ? new_state : 0;
+   can_change_state(net, cf, tx_state, rx_state);
+   netif_rx_ni(skb);
+
+   if (new_state == 

Re: [PATCH v4 2/2] can: spi: hi311x: Add Holt HI-311x CAN driver

2017-03-19 Thread Wolfgang Grandegger

Hello Akshay,

I still see some improvements...

Am 17.03.2017 um 22:10 schrieb Akshay Bhat:

This patch adds support for the Holt HI-311x CAN controller. The HI311x
CAN controller is capable of transmitting and receiving standard data
frames, extended data frames and remote frames. The HI311x interfaces
with the host over SPI.

Datasheet: www.holtic.com/documents/371-hi-3110_v-rev-jpdf.do

Signed-off-by: Akshay Bhat 
---

v3 -> v4:
Address comments from Wolfgang Grandegger:
- Add support for CAN warning state reporting
- Add support for reporting tx/rx error counts in bus error messages
- Keep bus error interrupts enabled to detect CAN state changes
- Fix bug in restart code after BUSOFF state
- Clean up error handling code

 drivers/net/can/spi/Kconfig  |6 +
 drivers/net/can/spi/Makefile |1 +
 drivers/net/can/spi/hi311x.c | 1072 ++
 3 files changed, 1079 insertions(+)
 create mode 100644 drivers/net/can/spi/hi311x.c

diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index 148cae5..8f2e0dd 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -1,6 +1,12 @@
 menu "CAN SPI interfaces"
depends on SPI

+config CAN_HI311X
+   tristate "Holt HI311x SPI CAN controllers"
+   depends on CAN_DEV && SPI && HAS_DMA
+   ---help---
+ Driver for the Holt HI311x SPI CAN controllers.
+
 config CAN_MCP251X
tristate "Microchip MCP251x SPI CAN controllers"
depends on HAS_DMA
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index 0e86040..f59fa37 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -3,4 +3,5 @@
 #


+obj-$(CONFIG_CAN_HI311X)   += hi311x.o
 obj-$(CONFIG_CAN_MCP251X)  += mcp251x.o
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
new file mode 100644
index 000..2a3d794
--- /dev/null
+++ b/drivers/net/can/spi/hi311x.c
@@ -0,0 +1,1072 @@
+/* CAN bus driver for Holt HI3110 CAN Controller with SPI Interface
+ *
+ * Copyright(C) Timesys Corporation 2016
+ *
+ * Based on Microchip 251x CAN Controller (mcp251x) Linux kernel driver
+ * Copyright 2009 Christian Pellegrin EVOL S.r.l.
+ * Copyright 2007 Raymarine UK, Ltd. All Rights Reserved.
+ * Copyright 2006 Arcom Control Systems Ltd.
+ *
+ * Based on CAN bus driver for the CCAN controller written by
+ * - Sascha Hauer, Marc Kleine-Budde, Pengutronix
+ * - Simon Kallweit, intefo AG
+ * Copyright 2007
+ *
+ * This program 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.
+ */


... snip...


+
+static irqreturn_t hi3110_can_ist(int irq, void *dev_id)
+{
+   struct hi3110_priv *priv = dev_id;
+   struct spi_device *spi = priv->spi;
+   struct net_device *net = priv->net;
+
+   mutex_lock(>hi3110_lock);
+
+   while (!priv->force_quit) {
+   enum can_state new_state;
+   u8 intf, eflag, statf;
+
+   while (!(HI3110_STAT_RXFMTY &
+  (statf = hi3110_read(spi, HI3110_READ_STATF {
+   hi3110_hw_rx(spi);
+   }
+
+   intf = hi3110_read(spi, HI3110_READ_INTF);


I think HI3110_READ_ERR is only valid if HI3110_INT_BUSERR is set! 
Therefore:


if ((intf & HI3110_INT_BUSERR) {

It saves reading one SPI register in the message processing path. Please 
check if back-to-error-active still comes.



+   eflag = hi3110_read(spi, HI3110_READ_ERR);
+   /* Update can state */
+   if (eflag & HI3110_ERR_BUSOFF)
+   new_state = CAN_STATE_BUS_OFF;
+   else if (eflag & HI3110_ERR_PASSIVE_MASK)
+   new_state = CAN_STATE_ERROR_PASSIVE;
+   else if (statf & HI3110_STAT_ERRW)
+   new_state = CAN_STATE_ERROR_WARNING;
+   else
+   new_state = CAN_STATE_ERROR_ACTIVE;
+
+   if (new_state != priv->can.state) {
+   struct can_frame *cf;
+   struct sk_buff *skb;
+   enum can_state rx_state, tx_state;
+   u8 rxerr, txerr;
+
+   skb = alloc_can_err_skb(net, );
+   if (!skb)
+   break;
+
+   txerr = hi3110_read(spi, HI3110_READ_TEC);
+   rxerr = hi3110_read(spi, HI3110_READ_REC);
+   cf->data[6] = txerr;
+   cf->data[7] = rxerr;
+   tx_state = txerr >= rxerr ? new_state : 0;
+   rx_state = txerr <= rxerr ? new_state : 0;
+   can_change_state(net, cf, tx_state, rx_state);
+   netif_rx_ni(skb);
+
+   if (new_state == CAN_STATE_BUS_OFF) {
+   

Re: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

2017-03-19 Thread Wei Yang
On Fri, Mar 17, 2017 at 10:50:34AM -0700, Thomas Garnier wrote:
>This patch remove fixmap header usage on non-x86 code that was
>introduced by the adaptable MODULE_END change.

Hi, Thomas

In this patch, it looks you are trying to do two things for my understanding:
1. To include  in asm/pagetable_64.h and remove the include in
some of the x86 files
2. Remove  in mm/vmalloc.c

I think your change log covers the second task in the patch, but not not talk
about the first task you did in the patch. If you could mention it in commit
log, it would be good for maintain.

BTW, I have little knowledge about MODULE_END. By searching the code
MODULE_END is not used in arch/x86. If you would like to mention the commit
which introduce the problem, it would be more helpful to review the code.

>
>Signed-off-by: Thomas Garnier 
>---
>Based on tip:x86/mm
>---
> arch/x86/include/asm/pgtable_64.h | 1 +
> arch/x86/kernel/module.c  | 1 -
> arch/x86/mm/dump_pagetables.c | 1 -
> arch/x86/mm/kasan_init_64.c   | 1 -
> mm/vmalloc.c  | 4 
> 5 files changed, 1 insertion(+), 7 deletions(-)
>
>diff --git a/arch/x86/include/asm/pgtable_64.h 
>b/arch/x86/include/asm/pgtable_64.h
>index 73c7ccc38912..67608d4abc2c 100644
>--- a/arch/x86/include/asm/pgtable_64.h
>+++ b/arch/x86/include/asm/pgtable_64.h
>@@ -13,6 +13,7 @@
> #include 
> #include 
> #include 
>+#include 
> 

Hmm... I see in both pgtable_32.h and pgtable_64.h will include 
after this change. And pgtable_32.h and pgtable_64.h will be included only in
pgtable.h. So is it possible to include  in pgtable.h for once
instead of include it in both files? Any concerns you would have?

> extern pud_t level3_kernel_pgt[512];
> extern pud_t level3_ident_pgt[512];
>diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
>index fad61caac75e..477ae806c2fa 100644
>--- a/arch/x86/kernel/module.c
>+++ b/arch/x86/kernel/module.c
>@@ -35,7 +35,6 @@
> #include 
> #include 
> #include 
>-#include 
> 
> #if 0
> #define DEBUGP(fmt, ...)  \
>diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
>index 75efeecc85eb..58b5bee7ea27 100644
>--- a/arch/x86/mm/dump_pagetables.c
>+++ b/arch/x86/mm/dump_pagetables.c
>@@ -20,7 +20,6 @@
> 
> #include 
> #include 
>-#include 
> 
> /*
>  * The dumper groups pagetable entries of the same type into one, and for
>diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
>index 1bde19ef86bd..8d63d7a104c3 100644
>--- a/arch/x86/mm/kasan_init_64.c
>+++ b/arch/x86/mm/kasan_init_64.c
>@@ -9,7 +9,6 @@
> 
> #include 
> #include 
>-#include 
> 
> extern pgd_t early_level4_pgt[PTRS_PER_PGD];
> extern struct range pfn_mapped[E820_X_MAX];
>diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>index b7d2a23349f4..0dd80222b20b 100644
>--- a/mm/vmalloc.c
>+++ b/mm/vmalloc.c
>@@ -36,10 +36,6 @@
> #include 
> #include 
> 
>-#ifdef CONFIG_X86
>-# include 
>-#endif
>-
> #include "internal.h"
> 
> struct vfree_deferred {
>-- 
>2.12.0.367.g23dc2f6d3c-goog

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH tip] x86/mm: Correct fixmap header usage on adaptable MODULES_END

2017-03-19 Thread Wei Yang
On Fri, Mar 17, 2017 at 10:50:34AM -0700, Thomas Garnier wrote:
>This patch remove fixmap header usage on non-x86 code that was
>introduced by the adaptable MODULE_END change.

Hi, Thomas

In this patch, it looks you are trying to do two things for my understanding:
1. To include  in asm/pagetable_64.h and remove the include in
some of the x86 files
2. Remove  in mm/vmalloc.c

I think your change log covers the second task in the patch, but not not talk
about the first task you did in the patch. If you could mention it in commit
log, it would be good for maintain.

BTW, I have little knowledge about MODULE_END. By searching the code
MODULE_END is not used in arch/x86. If you would like to mention the commit
which introduce the problem, it would be more helpful to review the code.

>
>Signed-off-by: Thomas Garnier 
>---
>Based on tip:x86/mm
>---
> arch/x86/include/asm/pgtable_64.h | 1 +
> arch/x86/kernel/module.c  | 1 -
> arch/x86/mm/dump_pagetables.c | 1 -
> arch/x86/mm/kasan_init_64.c   | 1 -
> mm/vmalloc.c  | 4 
> 5 files changed, 1 insertion(+), 7 deletions(-)
>
>diff --git a/arch/x86/include/asm/pgtable_64.h 
>b/arch/x86/include/asm/pgtable_64.h
>index 73c7ccc38912..67608d4abc2c 100644
>--- a/arch/x86/include/asm/pgtable_64.h
>+++ b/arch/x86/include/asm/pgtable_64.h
>@@ -13,6 +13,7 @@
> #include 
> #include 
> #include 
>+#include 
> 

Hmm... I see in both pgtable_32.h and pgtable_64.h will include 
after this change. And pgtable_32.h and pgtable_64.h will be included only in
pgtable.h. So is it possible to include  in pgtable.h for once
instead of include it in both files? Any concerns you would have?

> extern pud_t level3_kernel_pgt[512];
> extern pud_t level3_ident_pgt[512];
>diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
>index fad61caac75e..477ae806c2fa 100644
>--- a/arch/x86/kernel/module.c
>+++ b/arch/x86/kernel/module.c
>@@ -35,7 +35,6 @@
> #include 
> #include 
> #include 
>-#include 
> 
> #if 0
> #define DEBUGP(fmt, ...)  \
>diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
>index 75efeecc85eb..58b5bee7ea27 100644
>--- a/arch/x86/mm/dump_pagetables.c
>+++ b/arch/x86/mm/dump_pagetables.c
>@@ -20,7 +20,6 @@
> 
> #include 
> #include 
>-#include 
> 
> /*
>  * The dumper groups pagetable entries of the same type into one, and for
>diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
>index 1bde19ef86bd..8d63d7a104c3 100644
>--- a/arch/x86/mm/kasan_init_64.c
>+++ b/arch/x86/mm/kasan_init_64.c
>@@ -9,7 +9,6 @@
> 
> #include 
> #include 
>-#include 
> 
> extern pgd_t early_level4_pgt[PTRS_PER_PGD];
> extern struct range pfn_mapped[E820_X_MAX];
>diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>index b7d2a23349f4..0dd80222b20b 100644
>--- a/mm/vmalloc.c
>+++ b/mm/vmalloc.c
>@@ -36,10 +36,6 @@
> #include 
> #include 
> 
>-#ifdef CONFIG_X86
>-# include 
>-#endif
>-
> #include "internal.h"
> 
> struct vfree_deferred {
>-- 
>2.12.0.367.g23dc2f6d3c-goog

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH 4/4] mfd: cpcap: Fix bad use of IRQ sense register

2017-03-19 Thread Tony Lindgren
* Sebastian Reichel  [170318 19:03]:
> On Thu, Mar 16, 2017 at 05:36:33PM -0700, Tony Lindgren wrote:
> > The cpcap INTS registers are for getting the value of the line,
> > not for configuring the type.
> > 
> > Cc: Lee Jones 
> > Cc: Marcel Partap 
> > Cc: Michael Scott 
> > Cc: Sebastian Reichel 
> 
> Reviewed-By: Sebastian Reichel 
> 
> > Signed-off-by: Tony Lindgrne 
> 
> https://lwn.net/Articles/717281/ ;)

Nah, just a time to clean-up the keyboard again!

Tony


Re: [PATCH 4/4] mfd: cpcap: Fix bad use of IRQ sense register

2017-03-19 Thread Tony Lindgren
* Sebastian Reichel  [170318 19:03]:
> On Thu, Mar 16, 2017 at 05:36:33PM -0700, Tony Lindgren wrote:
> > The cpcap INTS registers are for getting the value of the line,
> > not for configuring the type.
> > 
> > Cc: Lee Jones 
> > Cc: Marcel Partap 
> > Cc: Michael Scott 
> > Cc: Sebastian Reichel 
> 
> Reviewed-By: Sebastian Reichel 
> 
> > Signed-off-by: Tony Lindgrne 
> 
> https://lwn.net/Articles/717281/ ;)

Nah, just a time to clean-up the keyboard again!

Tony


Re: [PATCH 4.4 08/35] MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change

2017-03-19 Thread Ben Hutchings
On Thu, 2017-03-16 at 23:29 +0900, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Arnd Bergmann 
> 
> commit b3f6046186ef45acfeebc5a59c9fb45cefc685e7 upstream.
> 
> Since linux-4.8, CPU_FREQ_STAT is a bool symbol, causing a warning in
> kernelci.org:
> 
> arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid for 
> CPU_FREQ_STAT
> 
> This updates the defconfig to have the feature built-in.
> 
> Fixes: 1aefc75b2449 ("cpufreq: stats: Make the stats code non-modular")
[...]

So not needed for 4.4?

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy
1981-1987



signature.asc
Description: This is a digitally signed message part


Re: [PATCH 4.4 08/35] MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change

2017-03-19 Thread Ben Hutchings
On Thu, 2017-03-16 at 23:29 +0900, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Arnd Bergmann 
> 
> commit b3f6046186ef45acfeebc5a59c9fb45cefc685e7 upstream.
> 
> Since linux-4.8, CPU_FREQ_STAT is a bool symbol, causing a warning in
> kernelci.org:
> 
> arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid for 
> CPU_FREQ_STAT
> 
> This updates the defconfig to have the feature built-in.
> 
> Fixes: 1aefc75b2449 ("cpufreq: stats: Make the stats code non-modular")
[...]

So not needed for 4.4?

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy
1981-1987



signature.asc
Description: This is a digitally signed message part


Re: [Outreachy kernel] [PATCH v3] staging: sm750fb: Code readability is improved

2017-03-19 Thread Geert Uytterhoeven
On Sun, Mar 19, 2017 at 4:52 PM, Arushi Singhal
 wrote:
> On Sun, Mar 19, 2017 at 7:34 PM, Geert Uytterhoeven 
> wrote:
>>
>> On Sun, Mar 19, 2017 at 2:11 PM, Julia Lawall 
>> wrote:
>> > On Sun, 19 Mar 2017, Arushi Singhal wrote:
>> >> New variables are added to make the code more readable.
>> >>
>> >> Signed-off-by: Arushi Singhal 
>> >> ---
>> >>  changes in v3
>> >>  -try to make the code much more readable.
>> >>
>> >>  drivers/staging/sm750fb/ddk750_mode.c | 61
>> >> ---
>> >>  1 file changed, 35 insertions(+), 26 deletions(-)
>> >>
>> >> diff --git a/drivers/staging/sm750fb/ddk750_mode.c
>> >> b/drivers/staging/sm750fb/ddk750_mode.c
>> >> index eea5aef2956f..5f18ce4d10de 100644
>> >> --- a/drivers/staging/sm750fb/ddk750_mode.c
>> >> +++ b/drivers/staging/sm750fb/ddk750_mode.c
>> >> @@ -81,33 +81,42 @@ static int programModeRegisters(mode_parameter_t
>> >> *pModeParam, struct pll_value *
>> >>   if (pll->clockType == SECONDARY_PLL) {
>> >>   /* programe secondary pixel clock */
>> >>   poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
>> >> - poke32(CRT_HORIZONTAL_TOTAL,
>> >> -(((pModeParam->horizontal_total - 1) <<
>> >> -  CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
>> >> - CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
>> >> -((pModeParam->horizontal_display_end - 1) &
>> >> - CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
>> >> -
>> >> - poke32(CRT_HORIZONTAL_SYNC,
>> >> -((pModeParam->horizontal_sync_width <<
>> >> -  CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
>> >> - CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
>> >> -((pModeParam->horizontal_sync_start - 1) &
>> >> - CRT_HORIZONTAL_SYNC_START_MASK));
>> >>
>> >> - poke32(CRT_VERTICAL_TOTAL,
>> >> -(((pModeParam->vertical_total - 1) <<
>> >> -  CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
>> >> - CRT_VERTICAL_TOTAL_TOTAL_MASK) |
>> >> -((pModeParam->vertical_display_end - 1) &
>> >> - CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
>> >> -
>> >> - poke32(CRT_VERTICAL_SYNC,
>> >> -((pModeParam->vertical_sync_height <<
>> >> -  CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
>> >> - CRT_VERTICAL_SYNC_HEIGHT_MASK) |
>> >> -((pModeParam->vertical_sync_start - 1) &
>> >> - CRT_VERTICAL_SYNC_START_MASK));
>> >> + unsigned int a = (pModeParam->horizontal_total - 1) <<
>> >> + CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT;
>> >> + unsigned int b = a & CRT_HORIZONTAL_TOTAL_TOTAL_MASK;
>> >> + unsigned int c = (pModeParam->horizontal_display_end - 1)
>> >> &
>> >> + CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK;
>> >> + unsigned int temp = b | c;
>> >> +
>> >> + poke32(CRT_HORIZONTAL_TOTAL, temp);
>> >> +
>> >> + unsigned int a = (pModeParam->horizontal_sync_width <<
>> >> + CRT_HORIZONTAL_SYNC_WIDTH_SHIFT);
>> >> + unsigned int b = a & CRT_HORIZONTAL_SYNC_WIDTH_MASK;
>> >> + unsigned int c = (pModeParam->horizontal_sync_start - 1)
>> >> &
>> >> + CRT_HORIZONTAL_SYNC_START_MASK;
>> >> + unsigned int temp = b | c;
>> >
>> > This is back to the original incorrect solution.  You can't declare
>> > variables on the fly in Linux code.  Variables have to be declared at
>> > the
>> > top of a block.
>>
>> Arushi: have you tried to compile this?
>
> Yes.
> It's not showing any error.

No, not an error.

> Is it not fine when you compiled :( ?

 But you did introduce warnings, like:

drivers/staging/sm750fb/ddk750_mode.c: In function 'programModeRegisters':
drivers/staging/sm750fb/ddk750_mode.c:87:3: warning: ISO C90 forbids
mixed declarations and code [-Wdeclaration-after-statement]

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [Outreachy kernel] [PATCH v3] staging: sm750fb: Code readability is improved

2017-03-19 Thread Geert Uytterhoeven
On Sun, Mar 19, 2017 at 4:52 PM, Arushi Singhal
 wrote:
> On Sun, Mar 19, 2017 at 7:34 PM, Geert Uytterhoeven 
> wrote:
>>
>> On Sun, Mar 19, 2017 at 2:11 PM, Julia Lawall 
>> wrote:
>> > On Sun, 19 Mar 2017, Arushi Singhal wrote:
>> >> New variables are added to make the code more readable.
>> >>
>> >> Signed-off-by: Arushi Singhal 
>> >> ---
>> >>  changes in v3
>> >>  -try to make the code much more readable.
>> >>
>> >>  drivers/staging/sm750fb/ddk750_mode.c | 61
>> >> ---
>> >>  1 file changed, 35 insertions(+), 26 deletions(-)
>> >>
>> >> diff --git a/drivers/staging/sm750fb/ddk750_mode.c
>> >> b/drivers/staging/sm750fb/ddk750_mode.c
>> >> index eea5aef2956f..5f18ce4d10de 100644
>> >> --- a/drivers/staging/sm750fb/ddk750_mode.c
>> >> +++ b/drivers/staging/sm750fb/ddk750_mode.c
>> >> @@ -81,33 +81,42 @@ static int programModeRegisters(mode_parameter_t
>> >> *pModeParam, struct pll_value *
>> >>   if (pll->clockType == SECONDARY_PLL) {
>> >>   /* programe secondary pixel clock */
>> >>   poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
>> >> - poke32(CRT_HORIZONTAL_TOTAL,
>> >> -(((pModeParam->horizontal_total - 1) <<
>> >> -  CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
>> >> - CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
>> >> -((pModeParam->horizontal_display_end - 1) &
>> >> - CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
>> >> -
>> >> - poke32(CRT_HORIZONTAL_SYNC,
>> >> -((pModeParam->horizontal_sync_width <<
>> >> -  CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
>> >> - CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
>> >> -((pModeParam->horizontal_sync_start - 1) &
>> >> - CRT_HORIZONTAL_SYNC_START_MASK));
>> >>
>> >> - poke32(CRT_VERTICAL_TOTAL,
>> >> -(((pModeParam->vertical_total - 1) <<
>> >> -  CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
>> >> - CRT_VERTICAL_TOTAL_TOTAL_MASK) |
>> >> -((pModeParam->vertical_display_end - 1) &
>> >> - CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
>> >> -
>> >> - poke32(CRT_VERTICAL_SYNC,
>> >> -((pModeParam->vertical_sync_height <<
>> >> -  CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
>> >> - CRT_VERTICAL_SYNC_HEIGHT_MASK) |
>> >> -((pModeParam->vertical_sync_start - 1) &
>> >> - CRT_VERTICAL_SYNC_START_MASK));
>> >> + unsigned int a = (pModeParam->horizontal_total - 1) <<
>> >> + CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT;
>> >> + unsigned int b = a & CRT_HORIZONTAL_TOTAL_TOTAL_MASK;
>> >> + unsigned int c = (pModeParam->horizontal_display_end - 1)
>> >> &
>> >> + CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK;
>> >> + unsigned int temp = b | c;
>> >> +
>> >> + poke32(CRT_HORIZONTAL_TOTAL, temp);
>> >> +
>> >> + unsigned int a = (pModeParam->horizontal_sync_width <<
>> >> + CRT_HORIZONTAL_SYNC_WIDTH_SHIFT);
>> >> + unsigned int b = a & CRT_HORIZONTAL_SYNC_WIDTH_MASK;
>> >> + unsigned int c = (pModeParam->horizontal_sync_start - 1)
>> >> &
>> >> + CRT_HORIZONTAL_SYNC_START_MASK;
>> >> + unsigned int temp = b | c;
>> >
>> > This is back to the original incorrect solution.  You can't declare
>> > variables on the fly in Linux code.  Variables have to be declared at
>> > the
>> > top of a block.
>>
>> Arushi: have you tried to compile this?
>
> Yes.
> It's not showing any error.

No, not an error.

> Is it not fine when you compiled :( ?

 But you did introduce warnings, like:

drivers/staging/sm750fb/ddk750_mode.c: In function 'programModeRegisters':
drivers/staging/sm750fb/ddk750_mode.c:87:3: warning: ISO C90 forbids
mixed declarations and code [-Wdeclaration-after-statement]

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH] mm: use BITS_PER_LONG to unify the definition in page->flags

2017-03-19 Thread Wei Yang
On Sun, Mar 19, 2017 at 11:08:22AM -0400, Michal Hocko wrote:
>On Sun 19-03-17 23:03:45, Wei Yang wrote:
>> On Sun, Mar 19, 2017 at 10:30:13AM -0400, Michal Hocko wrote:
>> >On Sat 18-03-17 08:39:14, Wei Yang wrote:
>> >> The field page->flags is defined as unsigned long and is divided into
>> >> several parts to store different information of the page, like section,
>> >> node, zone. Which means all parts must sit in the one "unsigned
>> >> long".
>> >> 
>> >> BITS_PER_LONG is used in several places to ensure this applies.
>> >> 
>> >> #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - 
>> >> NR_PAGEFLAGS
>> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT <= BITS_PER_LONG - 
>> >> NR_PAGEFLAGS
>> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= 
>> >> BITS_PER_LONG - NR_PAGEFLAGS
>> >> 
>> >> While we use "sizeof(unsigned long) * 8" in the definition of
>> >> SECTIONS_PGOFF
>> >> 
>> >> #define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - 
>> >> SECTIONS_WIDTH)
>> >> 
>> >> This may not be that obvious for audience to catch the point.
>> >> 
>> >> This patch replaces the "sizeof(unsigned long) * 8" with BITS_PER_LONG to
>> >> make all this consistent.
>> >
>> >I am not really sure this is an improvement. page::flags is unsigned
>> >long nad the current code reflects that type.
>> >
>> 
>> Hi, Michal
>> 
>> Glad to hear from you.
>> 
>> I think the purpose of definition BITS_PER_LONG is more easily to let 
>> audience
>> know it is the number of bits of type long. If it has no improvement, we 
>> don't
>> need to define a specific macro .
>> 
>> And as you could see, several related macros use BITS_PER_LONG in their
>> definition. After this change, all of them will have a consistent definition.
>> 
>> After this change, code looks more neat :-)
>> 
>> So it looks more reasonable to use this.
>
>I do not think that this is sufficient to justify the change.
>

Fine~ Thanks for comments~

>-- 
>Michal Hocko
>SUSE Labs

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH] mm: use BITS_PER_LONG to unify the definition in page->flags

2017-03-19 Thread Wei Yang
On Sun, Mar 19, 2017 at 11:08:22AM -0400, Michal Hocko wrote:
>On Sun 19-03-17 23:03:45, Wei Yang wrote:
>> On Sun, Mar 19, 2017 at 10:30:13AM -0400, Michal Hocko wrote:
>> >On Sat 18-03-17 08:39:14, Wei Yang wrote:
>> >> The field page->flags is defined as unsigned long and is divided into
>> >> several parts to store different information of the page, like section,
>> >> node, zone. Which means all parts must sit in the one "unsigned
>> >> long".
>> >> 
>> >> BITS_PER_LONG is used in several places to ensure this applies.
>> >> 
>> >> #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - 
>> >> NR_PAGEFLAGS
>> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT <= BITS_PER_LONG - 
>> >> NR_PAGEFLAGS
>> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= 
>> >> BITS_PER_LONG - NR_PAGEFLAGS
>> >> 
>> >> While we use "sizeof(unsigned long) * 8" in the definition of
>> >> SECTIONS_PGOFF
>> >> 
>> >> #define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - 
>> >> SECTIONS_WIDTH)
>> >> 
>> >> This may not be that obvious for audience to catch the point.
>> >> 
>> >> This patch replaces the "sizeof(unsigned long) * 8" with BITS_PER_LONG to
>> >> make all this consistent.
>> >
>> >I am not really sure this is an improvement. page::flags is unsigned
>> >long nad the current code reflects that type.
>> >
>> 
>> Hi, Michal
>> 
>> Glad to hear from you.
>> 
>> I think the purpose of definition BITS_PER_LONG is more easily to let 
>> audience
>> know it is the number of bits of type long. If it has no improvement, we 
>> don't
>> need to define a specific macro .
>> 
>> And as you could see, several related macros use BITS_PER_LONG in their
>> definition. After this change, all of them will have a consistent definition.
>> 
>> After this change, code looks more neat :-)
>> 
>> So it looks more reasonable to use this.
>
>I do not think that this is sufficient to justify the change.
>

Fine~ Thanks for comments~

>-- 
>Michal Hocko
>SUSE Labs

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: Still OOM problems with 4.9er/4.10er kernels

2017-03-19 Thread Gerhard Wiesinger

On 19.03.2017 16:18, Michal Hocko wrote:

On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:

On 17.03.2017 18:13, Michal Hocko wrote:

On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]

Why does the kernel prefer to swapin/out and not use

a.) the free memory?

It will use all the free memory up to min watermark which is set up
based on min_free_kbytes.

Makes sense, how is /proc/sys/vm/min_free_kbytes default value calculated?

See init_per_zone_wmark_min


b.) the buffer/cache?

the memory reclaim is strongly biased towards page cache and we try to
avoid swapout as much as possible (see get_scan_count).

If I understand it correctly, swapping is preferred over dropping the
cache, right. Can this behaviour be changed to prefer dropping the
cache to some minimum amount?  Is this also configurable in a way?

No, we enforce swapping if the amount of free + file pages are below the
cumulative high watermark.


(As far as I remember e.g. kernel 2.4 dropped the caches well).


There is ~100M memory available but kernel swaps all the time ...

Any ideas?

Kernel: 4.9.14-200.fc25.x86_64

top - 17:33:43 up 28 min,  3 users,  load average: 3.58, 1.67, 0.89
Tasks: 145 total,   4 running, 141 sleeping,   0 stopped,   0 zombie
%Cpu(s): 19.1 us, 56.2 sy,  0.0 ni,  4.3 id, 13.4 wa, 2.0 hi,  0.3 si,  4.7
st
KiB Mem :   230076 total,61508 free,   123472 used,45096 buff/cache

procs ---memory-- ---swap-- -io -system--
--cpu-
  r  b   swpd   free   buff  cache   si   sobibo in   cs us sy id wa st
  3  5 303916  60372328  43864 27828  200 41420   236 6984 11138 11 47  6 
23 14

I am really surprised to see any reclaim at all. 26% of free memory
doesn't sound as if we should do a reclaim at all. Do you have an
unusual configuration of /proc/sys/vm/min_free_kbytes ? Or is there
anything running inside a memory cgroup with a small limit?

nothing special set regarding /proc/sys/vm/min_free_kbytes (default values),
detailed config below. Regarding cgroups, none of I know. How to check (I
guess nothing is set because cg* commands are not available)?

be careful because systemd started to use some controllers. You can
easily check cgroup mount points.


See below.




/proc/sys/vm/min_free_kbytes
45056

So at least 45M will be kept reserved for the system. Your data
indicated you had more memory. How does /proc/zoneinfo look like?
Btw. you seem to be using fc kernel, are there any patches applied on
top of Linus tree? Could you try to retest vanilla kernel?



System looks normally now, FYI (e.g. now permanent swapping)


free
  totalusedfree  shared buff/cache   
available

Mem: 349076  154112   41560 184 153404  148716
Swap:   2064380  831844 1232536

cat /proc/zoneinfo

Node 0, zone  DMA
  per-node stats
  nr_inactive_anon 9543
  nr_active_anon 22105
  nr_inactive_file 9877
  nr_active_file 13416
  nr_unevictable 0
  nr_isolated_anon 0
  nr_isolated_file 0
  nr_pages_scanned 0
  workingset_refault 1926013
  workingset_activate 707166
  workingset_nodereclaim 187276
  nr_anon_pages 11429
  nr_mapped6852
  nr_file_pages 46772
  nr_dirty 1
  nr_writeback 0
  nr_writeback_temp 0
  nr_shmem 46
  nr_shmem_hugepages 0
  nr_shmem_pmdmapped 0
  nr_anon_transparent_hugepages 0
  nr_unstable  0
  nr_vmscan_write 3319047
  nr_vmscan_immediate_reclaim 32363
  nr_dirtied   222115
  nr_written   3537529
  pages free 3110
min  27
low  33
high 39
   node_scanned  0
spanned  4095
present  3998
managed  3977
  nr_free_pages 3110
  nr_zone_inactive_anon 18
  nr_zone_active_anon 3
  nr_zone_inactive_file 51
  nr_zone_active_file 75
  nr_zone_unevictable 0
  nr_zone_write_pending 0
  nr_mlock 0
  nr_slab_reclaimable 214
  nr_slab_unreclaimable 289
  nr_page_table_pages 185
  nr_kernel_stack 16
  nr_bounce0
  nr_zspages   0
  numa_hit 1214071
  numa_miss0
  numa_foreign 0
  numa_interleave 0
  numa_local   1214071
  numa_other   0
  nr_free_cma  0
protection: (0, 306, 306, 306, 306)
  pagesets
cpu: 0
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
cpu: 1
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
  node_unreclaimable:  0
  start_pfn:   1
  node_inactive_ratio: 0
Node 0, zoneDMA32
  pages free 7921
min  546
low  682
high 818
   node_scanned  0
spanned  94172
present  94172
managed  83292
  nr_free_pages 7921
  nr_zone_inactive_anon 9525
  nr_zone_active_anon 22102
  nr_zone_inactive_file 9826
  nr_zone_active_file 13341
  

Re: Still OOM problems with 4.9er/4.10er kernels

2017-03-19 Thread Gerhard Wiesinger

On 19.03.2017 16:18, Michal Hocko wrote:

On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:

On 17.03.2017 18:13, Michal Hocko wrote:

On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
[...]

Why does the kernel prefer to swapin/out and not use

a.) the free memory?

It will use all the free memory up to min watermark which is set up
based on min_free_kbytes.

Makes sense, how is /proc/sys/vm/min_free_kbytes default value calculated?

See init_per_zone_wmark_min


b.) the buffer/cache?

the memory reclaim is strongly biased towards page cache and we try to
avoid swapout as much as possible (see get_scan_count).

If I understand it correctly, swapping is preferred over dropping the
cache, right. Can this behaviour be changed to prefer dropping the
cache to some minimum amount?  Is this also configurable in a way?

No, we enforce swapping if the amount of free + file pages are below the
cumulative high watermark.


(As far as I remember e.g. kernel 2.4 dropped the caches well).


There is ~100M memory available but kernel swaps all the time ...

Any ideas?

Kernel: 4.9.14-200.fc25.x86_64

top - 17:33:43 up 28 min,  3 users,  load average: 3.58, 1.67, 0.89
Tasks: 145 total,   4 running, 141 sleeping,   0 stopped,   0 zombie
%Cpu(s): 19.1 us, 56.2 sy,  0.0 ni,  4.3 id, 13.4 wa, 2.0 hi,  0.3 si,  4.7
st
KiB Mem :   230076 total,61508 free,   123472 used,45096 buff/cache

procs ---memory-- ---swap-- -io -system--
--cpu-
  r  b   swpd   free   buff  cache   si   sobibo in   cs us sy id wa st
  3  5 303916  60372328  43864 27828  200 41420   236 6984 11138 11 47  6 
23 14

I am really surprised to see any reclaim at all. 26% of free memory
doesn't sound as if we should do a reclaim at all. Do you have an
unusual configuration of /proc/sys/vm/min_free_kbytes ? Or is there
anything running inside a memory cgroup with a small limit?

nothing special set regarding /proc/sys/vm/min_free_kbytes (default values),
detailed config below. Regarding cgroups, none of I know. How to check (I
guess nothing is set because cg* commands are not available)?

be careful because systemd started to use some controllers. You can
easily check cgroup mount points.


See below.




/proc/sys/vm/min_free_kbytes
45056

So at least 45M will be kept reserved for the system. Your data
indicated you had more memory. How does /proc/zoneinfo look like?
Btw. you seem to be using fc kernel, are there any patches applied on
top of Linus tree? Could you try to retest vanilla kernel?



System looks normally now, FYI (e.g. now permanent swapping)


free
  totalusedfree  shared buff/cache   
available

Mem: 349076  154112   41560 184 153404  148716
Swap:   2064380  831844 1232536

cat /proc/zoneinfo

Node 0, zone  DMA
  per-node stats
  nr_inactive_anon 9543
  nr_active_anon 22105
  nr_inactive_file 9877
  nr_active_file 13416
  nr_unevictable 0
  nr_isolated_anon 0
  nr_isolated_file 0
  nr_pages_scanned 0
  workingset_refault 1926013
  workingset_activate 707166
  workingset_nodereclaim 187276
  nr_anon_pages 11429
  nr_mapped6852
  nr_file_pages 46772
  nr_dirty 1
  nr_writeback 0
  nr_writeback_temp 0
  nr_shmem 46
  nr_shmem_hugepages 0
  nr_shmem_pmdmapped 0
  nr_anon_transparent_hugepages 0
  nr_unstable  0
  nr_vmscan_write 3319047
  nr_vmscan_immediate_reclaim 32363
  nr_dirtied   222115
  nr_written   3537529
  pages free 3110
min  27
low  33
high 39
   node_scanned  0
spanned  4095
present  3998
managed  3977
  nr_free_pages 3110
  nr_zone_inactive_anon 18
  nr_zone_active_anon 3
  nr_zone_inactive_file 51
  nr_zone_active_file 75
  nr_zone_unevictable 0
  nr_zone_write_pending 0
  nr_mlock 0
  nr_slab_reclaimable 214
  nr_slab_unreclaimable 289
  nr_page_table_pages 185
  nr_kernel_stack 16
  nr_bounce0
  nr_zspages   0
  numa_hit 1214071
  numa_miss0
  numa_foreign 0
  numa_interleave 0
  numa_local   1214071
  numa_other   0
  nr_free_cma  0
protection: (0, 306, 306, 306, 306)
  pagesets
cpu: 0
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
cpu: 1
  count: 0
  high:  0
  batch: 1
  vm stats threshold: 4
  node_unreclaimable:  0
  start_pfn:   1
  node_inactive_ratio: 0
Node 0, zoneDMA32
  pages free 7921
min  546
low  682
high 818
   node_scanned  0
spanned  94172
present  94172
managed  83292
  nr_free_pages 7921
  nr_zone_inactive_anon 9525
  nr_zone_active_anon 22102
  nr_zone_inactive_file 9826
  nr_zone_active_file 13341
  

Re: [PATCH] f2fs: don't allow volatile writes for non-regular file

2017-03-19 Thread kbuild test robot
Hi Chao,

[auto build test WARNING on f2fs/dev]
[also build test WARNING on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chao-Yu/f2fs-don-t-allow-volatile-writes-for-non-regular-file/20170319-221605
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:264:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> fs/f2fs/file.c:1598:14: sparse: incompatible types for operation (&)
   fs/f2fs/file.c:1598:14:left side has type struct inode *inode
   fs/f2fs/file.c:1598:14:right side has type int
   fs/f2fs/file.c:1598:14: sparse: incompatible types for operation (==)
   fs/f2fs/file.c:1598:14:left side has type bad type
   fs/f2fs/file.c:1598:14:right side has type int
   In file included from include/linux/stat.h:6:0,
from include/linux/fs.h:9,
from fs/f2fs/file.c:11:
   fs/f2fs/file.c: In function 'f2fs_ioc_start_volatile_write':
   include/uapi/linux/stat.h:20:26: error: invalid operands to binary & (have 
'struct inode *' and 'int')
#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
 ^
   fs/f2fs/file.c:1598:7: note: in expansion of macro 'S_ISREG'
 if (!S_ISREG(inode))
  ^~~

vim +1598 fs/f2fs/file.c

  1582  ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true);
  1583  }
  1584  err_out:
  1585  inode_unlock(inode);
  1586  mnt_drop_write_file(filp);
  1587  return ret;
  1588  }
  1589  
  1590  static int f2fs_ioc_start_volatile_write(struct file *filp)
  1591  {
  1592  struct inode *inode = file_inode(filp);
  1593  int ret;
  1594  
  1595  if (!inode_owner_or_capable(inode))
  1596  return -EACCES;
  1597  
> 1598  if (!S_ISREG(inode))
  1599  return -EINVAL;
  1600  
  1601  ret = mnt_want_write_file(filp);
  1602  if (ret)
  1603  return ret;
  1604  
  1605  inode_lock(inode);
  1606  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Re: [PATCH] f2fs: don't allow volatile writes for non-regular file

2017-03-19 Thread kbuild test robot
Hi Chao,

[auto build test WARNING on f2fs/dev]
[also build test WARNING on v4.11-rc2 next-20170310]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chao-Yu/f2fs-don-t-allow-volatile-writes-for-non-regular-file/20170319-221605
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:264:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> fs/f2fs/file.c:1598:14: sparse: incompatible types for operation (&)
   fs/f2fs/file.c:1598:14:left side has type struct inode *inode
   fs/f2fs/file.c:1598:14:right side has type int
   fs/f2fs/file.c:1598:14: sparse: incompatible types for operation (==)
   fs/f2fs/file.c:1598:14:left side has type bad type
   fs/f2fs/file.c:1598:14:right side has type int
   In file included from include/linux/stat.h:6:0,
from include/linux/fs.h:9,
from fs/f2fs/file.c:11:
   fs/f2fs/file.c: In function 'f2fs_ioc_start_volatile_write':
   include/uapi/linux/stat.h:20:26: error: invalid operands to binary & (have 
'struct inode *' and 'int')
#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
 ^
   fs/f2fs/file.c:1598:7: note: in expansion of macro 'S_ISREG'
 if (!S_ISREG(inode))
  ^~~

vim +1598 fs/f2fs/file.c

  1582  ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 0, true);
  1583  }
  1584  err_out:
  1585  inode_unlock(inode);
  1586  mnt_drop_write_file(filp);
  1587  return ret;
  1588  }
  1589  
  1590  static int f2fs_ioc_start_volatile_write(struct file *filp)
  1591  {
  1592  struct inode *inode = file_inode(filp);
  1593  int ret;
  1594  
  1595  if (!inode_owner_or_capable(inode))
  1596  return -EACCES;
  1597  
> 1598  if (!S_ISREG(inode))
  1599  return -EINVAL;
  1600  
  1601  ret = mnt_want_write_file(filp);
  1602  if (ret)
  1603  return ret;
  1604  
  1605  inode_lock(inode);
  1606  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Re: [PATCH] braille-console: Fix value returned by _braille_console_setup

2017-03-19 Thread Samuel Thibault
Aleksey Makarov, on dim. 19 mars 2017 18:44:23 +0300, wrote:
> On 03/19/2017 05:37 PM, Samuel Thibault wrote:
> > commit bbeddf52adc1 ("printk: move braille console support into
> > separate braille.[ch] files") introduced _braille_console_setup()
> > to outline the braille initialization code.  There was however some
> > confusion over the value it was supposed to return. commit 2cfe6c4ac7ee
> > ("printk: Fix return of braille_register_console()") tried to fix it
> > but failed to.
> > 
> > This fixes and documents the returned value according to the use
> > in printk.c: non-zero return means a parsing error, and thus this
> > console configuration should be ignored.
> 
> Did you test the code on real braille hardware?

Not on actual hardware, but I checked that the output on the serial port
is what is expected.

> I am asking because there could also be other problems with the code
> that have not been run for 3 years since it was changed.

The code which actually implements the braille protocol has not changed
since it was tested.

Samuel


Re: [PATCH] braille-console: Fix value returned by _braille_console_setup

2017-03-19 Thread Samuel Thibault
Aleksey Makarov, on dim. 19 mars 2017 18:44:23 +0300, wrote:
> On 03/19/2017 05:37 PM, Samuel Thibault wrote:
> > commit bbeddf52adc1 ("printk: move braille console support into
> > separate braille.[ch] files") introduced _braille_console_setup()
> > to outline the braille initialization code.  There was however some
> > confusion over the value it was supposed to return. commit 2cfe6c4ac7ee
> > ("printk: Fix return of braille_register_console()") tried to fix it
> > but failed to.
> > 
> > This fixes and documents the returned value according to the use
> > in printk.c: non-zero return means a parsing error, and thus this
> > console configuration should be ignored.
> 
> Did you test the code on real braille hardware?

Not on actual hardware, but I checked that the output on the serial port
is what is expected.

> I am asking because there could also be other problems with the code
> that have not been run for 3 years since it was changed.

The code which actually implements the braille protocol has not changed
since it was tested.

Samuel


[PATCH v4] staging: sm750fb: Code readability is improved

2017-03-19 Thread Arushi Singhal
New variables are added to make the code more readable.

Signed-off-by: Arushi Singhal 
---
 changes in v4
 -try to make the code much more readable.
 - defined the variable at the top of a block.
---
 drivers/staging/sm750fb/ddk750_mode.c | 57 +++
 1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index eea5aef2956f..6517e770e0a7 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -76,38 +76,43 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam, struct pll_value *
 {
int ret = 0;
int cnt = 0;
-   unsigned int tmp, reg;
+   unsigned int tmp, reg, temp;
 
if (pll->clockType == SECONDARY_PLL) {
/* programe secondary pixel clock */
poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
-   poke32(CRT_HORIZONTAL_TOTAL,
-  (((pModeParam->horizontal_total - 1) <<
-CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
-   CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
-  ((pModeParam->horizontal_display_end - 1) &
-   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
-
-   poke32(CRT_HORIZONTAL_SYNC,
-  ((pModeParam->horizontal_sync_width <<
-CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
-   CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
-  ((pModeParam->horizontal_sync_start - 1) &
-   CRT_HORIZONTAL_SYNC_START_MASK));
 
-   poke32(CRT_VERTICAL_TOTAL,
-  (((pModeParam->vertical_total - 1) <<
-CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
-   CRT_VERTICAL_TOTAL_TOTAL_MASK) |
-  ((pModeParam->vertical_display_end - 1) &
-   CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
+   temp = (pModeParam->horizontal_total - 1) <<
+   CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT;
+   temp = temp & CRT_HORIZONTAL_TOTAL_TOTAL_MASK;
+   temp = temp | ((pModeParam->horizontal_display_end - 1) &
+   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK);
 
-   poke32(CRT_VERTICAL_SYNC,
-  ((pModeParam->vertical_sync_height <<
-CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
-   CRT_VERTICAL_SYNC_HEIGHT_MASK) |
-  ((pModeParam->vertical_sync_start - 1) &
-   CRT_VERTICAL_SYNC_START_MASK));
+   poke32(CRT_HORIZONTAL_TOTAL, temp);
+
+   temp = (pModeParam->horizontal_sync_width <<
+   CRT_HORIZONTAL_SYNC_WIDTH_SHIFT);
+   temp = temp & CRT_HORIZONTAL_SYNC_WIDTH_MASK;
+   temp = temp | ((pModeParam->horizontal_sync_start - 1) &
+   CRT_HORIZONTAL_SYNC_START_MASK);
+
+   poke32(CRT_HORIZONTAL_SYNC, temp);
+
+   temp = (pModeParam->vertical_total - 1) <<
+   CRT_VERTICAL_TOTAL_TOTAL_SHIFT;
+   temp = temp & CRT_VERTICAL_TOTAL_TOTAL_MASK;
+   temp = temp | ((pModeParam->vertical_display_end - 1) &
+  CRT_VERTICAL_TOTAL_DISPLAY_END_MASK);
+
+   poke32(CRT_VERTICAL_TOTAL, temp);
+
+   temp = pModeParam->vertical_sync_height <<
+   CRT_VERTICAL_SYNC_HEIGHT_SHIFT;
+   temp = temp & CRT_VERTICAL_SYNC_HEIGHT_MASK;
+   temp = temp | ((pModeParam->vertical_sync_start - 1) &
+  CRT_VERTICAL_SYNC_START_MASK);
+
+   poke32(CRT_VERTICAL_SYNC, temp);
 
tmp = DISPLAY_CTRL_TIMING | DISPLAY_CTRL_PLANE;
if (pModeParam->vertical_sync_polarity)
-- 
2.11.0



[PATCH v4] staging: sm750fb: Code readability is improved

2017-03-19 Thread Arushi Singhal
New variables are added to make the code more readable.

Signed-off-by: Arushi Singhal 
---
 changes in v4
 -try to make the code much more readable.
 - defined the variable at the top of a block.
---
 drivers/staging/sm750fb/ddk750_mode.c | 57 +++
 1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index eea5aef2956f..6517e770e0a7 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -76,38 +76,43 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam, struct pll_value *
 {
int ret = 0;
int cnt = 0;
-   unsigned int tmp, reg;
+   unsigned int tmp, reg, temp;
 
if (pll->clockType == SECONDARY_PLL) {
/* programe secondary pixel clock */
poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
-   poke32(CRT_HORIZONTAL_TOTAL,
-  (((pModeParam->horizontal_total - 1) <<
-CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
-   CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
-  ((pModeParam->horizontal_display_end - 1) &
-   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
-
-   poke32(CRT_HORIZONTAL_SYNC,
-  ((pModeParam->horizontal_sync_width <<
-CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
-   CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
-  ((pModeParam->horizontal_sync_start - 1) &
-   CRT_HORIZONTAL_SYNC_START_MASK));
 
-   poke32(CRT_VERTICAL_TOTAL,
-  (((pModeParam->vertical_total - 1) <<
-CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
-   CRT_VERTICAL_TOTAL_TOTAL_MASK) |
-  ((pModeParam->vertical_display_end - 1) &
-   CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
+   temp = (pModeParam->horizontal_total - 1) <<
+   CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT;
+   temp = temp & CRT_HORIZONTAL_TOTAL_TOTAL_MASK;
+   temp = temp | ((pModeParam->horizontal_display_end - 1) &
+   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK);
 
-   poke32(CRT_VERTICAL_SYNC,
-  ((pModeParam->vertical_sync_height <<
-CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
-   CRT_VERTICAL_SYNC_HEIGHT_MASK) |
-  ((pModeParam->vertical_sync_start - 1) &
-   CRT_VERTICAL_SYNC_START_MASK));
+   poke32(CRT_HORIZONTAL_TOTAL, temp);
+
+   temp = (pModeParam->horizontal_sync_width <<
+   CRT_HORIZONTAL_SYNC_WIDTH_SHIFT);
+   temp = temp & CRT_HORIZONTAL_SYNC_WIDTH_MASK;
+   temp = temp | ((pModeParam->horizontal_sync_start - 1) &
+   CRT_HORIZONTAL_SYNC_START_MASK);
+
+   poke32(CRT_HORIZONTAL_SYNC, temp);
+
+   temp = (pModeParam->vertical_total - 1) <<
+   CRT_VERTICAL_TOTAL_TOTAL_SHIFT;
+   temp = temp & CRT_VERTICAL_TOTAL_TOTAL_MASK;
+   temp = temp | ((pModeParam->vertical_display_end - 1) &
+  CRT_VERTICAL_TOTAL_DISPLAY_END_MASK);
+
+   poke32(CRT_VERTICAL_TOTAL, temp);
+
+   temp = pModeParam->vertical_sync_height <<
+   CRT_VERTICAL_SYNC_HEIGHT_SHIFT;
+   temp = temp & CRT_VERTICAL_SYNC_HEIGHT_MASK;
+   temp = temp | ((pModeParam->vertical_sync_start - 1) &
+  CRT_VERTICAL_SYNC_START_MASK);
+
+   poke32(CRT_VERTICAL_SYNC, temp);
 
tmp = DISPLAY_CTRL_TIMING | DISPLAY_CTRL_PLANE;
if (pModeParam->vertical_sync_polarity)
-- 
2.11.0



Re: [PATCH] braille-console: Fix value returned by _braille_console_setup

2017-03-19 Thread Aleksey Makarov



On 03/19/2017 05:37 PM, Samuel Thibault wrote:

commit bbeddf52adc1 ("printk: move braille console support into
separate braille.[ch] files") introduced _braille_console_setup()
to outline the braille initialization code.  There was however some
confusion over the value it was supposed to return. commit 2cfe6c4ac7ee
("printk: Fix return of braille_register_console()") tried to fix it
but failed to.

This fixes and documents the returned value according to the use
in printk.c: non-zero return means a parsing error, and thus this
console configuration should be ignored.


Did you test the code on real braille hardware?
I am asking because there could also be other problems with the code
that have not been run for 3 years since it was changed.

Thank you
Aleksey Makarov


Signed-off-by: Samuel Thibault 
Cc: Aleksey Makarov 
Cc: Joe Perches 
Cc: Ming Lei 
Cc: Steven Rostedt 
Cc: Petr Mladek 

Index: linux-4.10/kernel/printk/braille.c
===
--- linux-4.10.orig/kernel/printk/braille.c
+++ linux-4.10/kernel/printk/braille.c
@@ -2,12 +2,13 @@

 #include 
 #include 
+#include 
 #include 

 #include "console_cmdline.h"
 #include "braille.h"

-char *_braille_console_setup(char **str, char **brl_options)
+int _braille_console_setup(char **str, char **brl_options)
 {
if (!strncmp(*str, "brl,", 4)) {
*brl_options = "";
@@ -15,14 +16,15 @@ char *_braille_console_setup(char **str,
} else if (!strncmp(*str, "brl=", 4)) {
*brl_options = *str + 4;
*str = strchr(*brl_options, ',');
-   if (!*str)
+   if (!*str) {
pr_err("need port name after brl=\n");
+   return -EINVAL;
+   }
else
*((*str)++) = 0;
-   } else
-   return NULL;
+   }

-   return *str;
+   return 0;
 }

 int
Index: linux-4.10/kernel/printk/braille.h
===
--- linux-4.10.orig/kernel/printk/braille.h
+++ linux-4.10/kernel/printk/braille.h
@@ -9,7 +9,14 @@ braille_set_options(struct console_cmdli
c->brl_options = brl_options;
 }

-char *
+/*
+ * Setup console according to braille options.
+ * Return -EINVAL on syntax error, 0 on success (or no braille option was
+ * actually given).
+ * Modifies str to point to the serial options
+ * Sets brl_options to the parsed braille options.
+ */
+int
 _braille_console_setup(char **str, char **brl_options);

 int
@@ -25,10 +32,10 @@ braille_set_options(struct console_cmdli
 {
 }

-static inline char *
+static inline int
 _braille_console_setup(char **str, char **brl_options)
 {
-   return NULL;
+   return 0;
 }

 static inline int



Re: [PATCH] braille-console: Fix value returned by _braille_console_setup

2017-03-19 Thread Aleksey Makarov



On 03/19/2017 05:37 PM, Samuel Thibault wrote:

commit bbeddf52adc1 ("printk: move braille console support into
separate braille.[ch] files") introduced _braille_console_setup()
to outline the braille initialization code.  There was however some
confusion over the value it was supposed to return. commit 2cfe6c4ac7ee
("printk: Fix return of braille_register_console()") tried to fix it
but failed to.

This fixes and documents the returned value according to the use
in printk.c: non-zero return means a parsing error, and thus this
console configuration should be ignored.


Did you test the code on real braille hardware?
I am asking because there could also be other problems with the code
that have not been run for 3 years since it was changed.

Thank you
Aleksey Makarov


Signed-off-by: Samuel Thibault 
Cc: Aleksey Makarov 
Cc: Joe Perches 
Cc: Ming Lei 
Cc: Steven Rostedt 
Cc: Petr Mladek 

Index: linux-4.10/kernel/printk/braille.c
===
--- linux-4.10.orig/kernel/printk/braille.c
+++ linux-4.10/kernel/printk/braille.c
@@ -2,12 +2,13 @@

 #include 
 #include 
+#include 
 #include 

 #include "console_cmdline.h"
 #include "braille.h"

-char *_braille_console_setup(char **str, char **brl_options)
+int _braille_console_setup(char **str, char **brl_options)
 {
if (!strncmp(*str, "brl,", 4)) {
*brl_options = "";
@@ -15,14 +16,15 @@ char *_braille_console_setup(char **str,
} else if (!strncmp(*str, "brl=", 4)) {
*brl_options = *str + 4;
*str = strchr(*brl_options, ',');
-   if (!*str)
+   if (!*str) {
pr_err("need port name after brl=\n");
+   return -EINVAL;
+   }
else
*((*str)++) = 0;
-   } else
-   return NULL;
+   }

-   return *str;
+   return 0;
 }

 int
Index: linux-4.10/kernel/printk/braille.h
===
--- linux-4.10.orig/kernel/printk/braille.h
+++ linux-4.10/kernel/printk/braille.h
@@ -9,7 +9,14 @@ braille_set_options(struct console_cmdli
c->brl_options = brl_options;
 }

-char *
+/*
+ * Setup console according to braille options.
+ * Return -EINVAL on syntax error, 0 on success (or no braille option was
+ * actually given).
+ * Modifies str to point to the serial options
+ * Sets brl_options to the parsed braille options.
+ */
+int
 _braille_console_setup(char **str, char **brl_options);

 int
@@ -25,10 +32,10 @@ braille_set_options(struct console_cmdli
 {
 }

-static inline char *
+static inline int
 _braille_console_setup(char **str, char **brl_options)
 {
-   return NULL;
+   return 0;
 }

 static inline int



[PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

2017-03-19 Thread Mars Cheng
Originally driver only supports one base. However, MT6797 has
more than one bases to configure interrupt polarity. To support
possible design change, here comes a solution to use arbitrary
number of bases.

Signed-off-by: Mars Cheng 
---
 drivers/irqchip/irq-mtk-sysirq.c |  116 +++---
 1 file changed, 95 insertions(+), 21 deletions(-)

diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index 63ac73b..9ba969c 100644
--- a/drivers/irqchip/irq-mtk-sysirq.c
+++ b/drivers/irqchip/irq-mtk-sysirq.c
@@ -24,22 +24,29 @@
 
 struct mtk_sysirq_chip_data {
spinlock_t lock;
-   void __iomem *intpol_base;
+   u32 nr_intpol_bases;
+   void __iomem **intpol_bases;
+   u32 *intpol_words;
+   u8 *intpol_idx;
+   u16 *which_word;
 };
 
 static int mtk_sysirq_set_type(struct irq_data *data, unsigned int type)
 {
irq_hw_number_t hwirq = data->hwirq;
struct mtk_sysirq_chip_data *chip_data = data->chip_data;
+   u8 intpol_idx = chip_data->intpol_idx[hwirq];
+   void __iomem *base;
u32 offset, reg_index, value;
unsigned long flags;
int ret;
 
+   base = chip_data->intpol_bases[intpol_idx];
+   reg_index = chip_data->which_word[hwirq];
offset = hwirq & 0x1f;
-   reg_index = hwirq >> 5;
 
spin_lock_irqsave(_data->lock, flags);
-   value = readl_relaxed(chip_data->intpol_base + reg_index * 4);
+   value = readl_relaxed(base + reg_index * 4);
if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING) {
if (type == IRQ_TYPE_LEVEL_LOW)
type = IRQ_TYPE_LEVEL_HIGH;
@@ -49,7 +56,8 @@ static int mtk_sysirq_set_type(struct irq_data *data, 
unsigned int type)
} else {
value &= ~(1 << offset);
}
-   writel(value, chip_data->intpol_base + reg_index * 4);
+
+   writel(value, base + reg_index * 4);
 
data = data->parent_data;
ret = data->chip->irq_set_type(data, type);
@@ -124,8 +132,7 @@ static int __init mtk_sysirq_of_init(struct device_node 
*node,
 {
struct irq_domain *domain, *domain_parent;
struct mtk_sysirq_chip_data *chip_data;
-   int ret, size, intpol_num;
-   struct resource res;
+   int ret, size, intpol_num = 0, nr_intpol_bases = 0, i = 0;
 
domain_parent = irq_find_host(parent);
if (!domain_parent) {
@@ -133,36 +140,103 @@ static int __init mtk_sysirq_of_init(struct device_node 
*node,
return -EINVAL;
}
 
-   ret = of_address_to_resource(node, 0, );
-   if (ret)
-   return ret;
-
chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
if (!chip_data)
return -ENOMEM;
 
-   size = resource_size();
-   intpol_num = size * 8;
-   chip_data->intpol_base = ioremap(res.start, size);
-   if (!chip_data->intpol_base) {
-   pr_err("mtk_sysirq: unable to map sysirq register\n");
-   ret = -ENXIO;
-   goto out_free;
+   while (of_get_address(node, i++, NULL, NULL))
+   nr_intpol_bases++;
+
+   if (nr_intpol_bases == 0) {
+   pr_err("mtk_sysirq: base address not specified\n");
+   ret = -EINVAL;
+   goto out_free_chip;
+   }
+
+   chip_data->intpol_words = kcalloc(nr_intpol_bases,
+ sizeof(*chip_data->intpol_words),
+ GFP_KERNEL);
+   if (!chip_data->intpol_words) {
+   ret = -ENOMEM;
+   goto out_free_chip;
+   }
+
+   chip_data->intpol_bases = kcalloc(nr_intpol_bases,
+ sizeof(*chip_data->intpol_bases),
+ GFP_KERNEL);
+   if (!chip_data->intpol_bases) {
+   ret = -ENOMEM;
+   goto out_free_intpol_words;
+   }
+
+   for (i = 0; i < nr_intpol_bases; i++) {
+   struct resource res;
+
+   ret = of_address_to_resource(node, i, );
+   size = resource_size();
+   intpol_num += size * 8;
+   chip_data->intpol_words[i] = size / 4;
+   chip_data->intpol_bases[i] = of_iomap(node, i);
+   if (ret || !chip_data->intpol_bases[i]) {
+   pr_err("%s: couldn't map region %d\n",
+  node->full_name, i);
+   ret = -ENODEV;
+   goto out_free_intpol;
+   }
+   }
+
+   chip_data->intpol_idx = kcalloc(intpol_num,
+   sizeof(*chip_data->intpol_idx),
+   GFP_KERNEL);
+   if (!chip_data->intpol_idx) {
+   ret = -ENOMEM;
+   goto out_free_intpol;
+   }
+
+   chip_data->which_word = kcalloc(intpol_num,
+

[PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

2017-03-19 Thread Mars Cheng
Originally driver only supports one base. However, MT6797 has
more than one bases to configure interrupt polarity. To support
possible design change, here comes a solution to use arbitrary
number of bases.

Signed-off-by: Mars Cheng 
---
 drivers/irqchip/irq-mtk-sysirq.c |  116 +++---
 1 file changed, 95 insertions(+), 21 deletions(-)

diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index 63ac73b..9ba969c 100644
--- a/drivers/irqchip/irq-mtk-sysirq.c
+++ b/drivers/irqchip/irq-mtk-sysirq.c
@@ -24,22 +24,29 @@
 
 struct mtk_sysirq_chip_data {
spinlock_t lock;
-   void __iomem *intpol_base;
+   u32 nr_intpol_bases;
+   void __iomem **intpol_bases;
+   u32 *intpol_words;
+   u8 *intpol_idx;
+   u16 *which_word;
 };
 
 static int mtk_sysirq_set_type(struct irq_data *data, unsigned int type)
 {
irq_hw_number_t hwirq = data->hwirq;
struct mtk_sysirq_chip_data *chip_data = data->chip_data;
+   u8 intpol_idx = chip_data->intpol_idx[hwirq];
+   void __iomem *base;
u32 offset, reg_index, value;
unsigned long flags;
int ret;
 
+   base = chip_data->intpol_bases[intpol_idx];
+   reg_index = chip_data->which_word[hwirq];
offset = hwirq & 0x1f;
-   reg_index = hwirq >> 5;
 
spin_lock_irqsave(_data->lock, flags);
-   value = readl_relaxed(chip_data->intpol_base + reg_index * 4);
+   value = readl_relaxed(base + reg_index * 4);
if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING) {
if (type == IRQ_TYPE_LEVEL_LOW)
type = IRQ_TYPE_LEVEL_HIGH;
@@ -49,7 +56,8 @@ static int mtk_sysirq_set_type(struct irq_data *data, 
unsigned int type)
} else {
value &= ~(1 << offset);
}
-   writel(value, chip_data->intpol_base + reg_index * 4);
+
+   writel(value, base + reg_index * 4);
 
data = data->parent_data;
ret = data->chip->irq_set_type(data, type);
@@ -124,8 +132,7 @@ static int __init mtk_sysirq_of_init(struct device_node 
*node,
 {
struct irq_domain *domain, *domain_parent;
struct mtk_sysirq_chip_data *chip_data;
-   int ret, size, intpol_num;
-   struct resource res;
+   int ret, size, intpol_num = 0, nr_intpol_bases = 0, i = 0;
 
domain_parent = irq_find_host(parent);
if (!domain_parent) {
@@ -133,36 +140,103 @@ static int __init mtk_sysirq_of_init(struct device_node 
*node,
return -EINVAL;
}
 
-   ret = of_address_to_resource(node, 0, );
-   if (ret)
-   return ret;
-
chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
if (!chip_data)
return -ENOMEM;
 
-   size = resource_size();
-   intpol_num = size * 8;
-   chip_data->intpol_base = ioremap(res.start, size);
-   if (!chip_data->intpol_base) {
-   pr_err("mtk_sysirq: unable to map sysirq register\n");
-   ret = -ENXIO;
-   goto out_free;
+   while (of_get_address(node, i++, NULL, NULL))
+   nr_intpol_bases++;
+
+   if (nr_intpol_bases == 0) {
+   pr_err("mtk_sysirq: base address not specified\n");
+   ret = -EINVAL;
+   goto out_free_chip;
+   }
+
+   chip_data->intpol_words = kcalloc(nr_intpol_bases,
+ sizeof(*chip_data->intpol_words),
+ GFP_KERNEL);
+   if (!chip_data->intpol_words) {
+   ret = -ENOMEM;
+   goto out_free_chip;
+   }
+
+   chip_data->intpol_bases = kcalloc(nr_intpol_bases,
+ sizeof(*chip_data->intpol_bases),
+ GFP_KERNEL);
+   if (!chip_data->intpol_bases) {
+   ret = -ENOMEM;
+   goto out_free_intpol_words;
+   }
+
+   for (i = 0; i < nr_intpol_bases; i++) {
+   struct resource res;
+
+   ret = of_address_to_resource(node, i, );
+   size = resource_size();
+   intpol_num += size * 8;
+   chip_data->intpol_words[i] = size / 4;
+   chip_data->intpol_bases[i] = of_iomap(node, i);
+   if (ret || !chip_data->intpol_bases[i]) {
+   pr_err("%s: couldn't map region %d\n",
+  node->full_name, i);
+   ret = -ENODEV;
+   goto out_free_intpol;
+   }
+   }
+
+   chip_data->intpol_idx = kcalloc(intpol_num,
+   sizeof(*chip_data->intpol_idx),
+   GFP_KERNEL);
+   if (!chip_data->intpol_idx) {
+   ret = -ENOMEM;
+   goto out_free_intpol;
+   }
+
+   chip_data->which_word = kcalloc(intpol_num,
+ 

[PATCH v3 06/12] dt-bindings: arm: mediatek: document clk bindings for MT6797

2017-03-19 Thread Mars Cheng
From: Kevin-CW Chen 

This patch adds the binding documentation for apmixedsys, imgsys,
infracfg, mmsys, topckgen, vdecsys and vencsys for MT6797.

Signed-off-by: Kevin-CW Chen 
Signed-off-by: Mars Cheng 
Acked-by: Rob Herring 
---
 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |3 ++-
 7 files changed, 8 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
index cb0054a..cd977db 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
+   - "mediatek,mt6797-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8173-apmixedsys"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index f6a9166..047b11a 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-imgsys", "syscon"
+   - "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
index 1620ec2..58d58e2 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -8,6 +8,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
+   - "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 67dd2e4..70529e0 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-mmsys", "syscon"
+   - "mediatek,mt6797-mmsys", "syscon"
- "mediatek,mt8173-mmsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
index 9f2fe78..ec93ecb 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-topckgen"
+   - "mediatek,mt6797-topckgen"
- "mediatek,mt8135-topckgen"
- "mediatek,mt8173-topckgen"
 - #clock-cells: Must be 1
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
index 2440f73..d150104 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-vdecsys", "syscon"
+   - "mediatek,mt6797-vdecsys", "syscon"
- "mediatek,mt8173-vdecsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
index 5bb2866..8a93be6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
@@ -5,7 +5,8 @@ The Mediatek vencsys controller provides various clocks to the 
system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+   - "mediatek,mt6797-vencsys", "syscon"
- "mediatek,mt8173-vencsys", "syscon"
 - #clock-cells: Must be 1
 
-- 
1.7.9.5



[PATCH v3 06/12] dt-bindings: arm: mediatek: document clk bindings for MT6797

2017-03-19 Thread Mars Cheng
From: Kevin-CW Chen 

This patch adds the binding documentation for apmixedsys, imgsys,
infracfg, mmsys, topckgen, vdecsys and vencsys for MT6797.

Signed-off-by: Kevin-CW Chen 
Signed-off-by: Mars Cheng 
Acked-by: Rob Herring 
---
 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |3 ++-
 7 files changed, 8 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
index cb0054a..cd977db 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
+   - "mediatek,mt6797-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8173-apmixedsys"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index f6a9166..047b11a 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-imgsys", "syscon"
+   - "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
index 1620ec2..58d58e2 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -8,6 +8,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
+   - "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 67dd2e4..70529e0 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-mmsys", "syscon"
+   - "mediatek,mt6797-mmsys", "syscon"
- "mediatek,mt8173-mmsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
index 9f2fe78..ec93ecb 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-topckgen"
+   - "mediatek,mt6797-topckgen"
- "mediatek,mt8135-topckgen"
- "mediatek,mt8173-topckgen"
 - #clock-cells: Must be 1
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
index 2440f73..d150104 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: Should be one of:
- "mediatek,mt2701-vdecsys", "syscon"
+   - "mediatek,mt6797-vdecsys", "syscon"
- "mediatek,mt8173-vdecsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
index 5bb2866..8a93be6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
@@ -5,7 +5,8 @@ The Mediatek vencsys controller provides various clocks to the 
system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+   - "mediatek,mt6797-vencsys", "syscon"
- "mediatek,mt8173-vencsys", "syscon"
 - #clock-cells: Must be 1
 
-- 
1.7.9.5



[PATCH v3 05/12] arm64: dts: mediatek: add mt6797 support

2017-03-19 Thread Mars Cheng
This adds basic chip support for MT6797 SoC.

Signed-off-by: Mars Cheng 
---
 arch/arm64/boot/dts/mediatek/Makefile   |1 +
 arch/arm64/boot/dts/mediatek/mt6797-evb.dts |   36 ++
 arch/arm64/boot/dts/mediatek/mt6797.dtsi|  182 +++
 3 files changed, 219 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index 9fbfd32..015eb07 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/mediatek/mt6797-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt6797-evb.dts
new file mode 100644
index 000..c79109c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797-evb.dts
@@ -0,0 +1,36 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * This program 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 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.
+ */
+
+/dts-v1/;
+#include "mt6797.dtsi"
+
+/ {
+   model = "MediaTek MT6797 Evaluation Board";
+   compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
+
+   aliases {
+   serial0 = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x1e80>;
+   };
+
+   chosen {};
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
new file mode 100644
index 000..cf4529e
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -0,0 +1,182 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * This program 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 program is distributed in the hope that it will be useful,
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt6797";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x000>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x001>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x002>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x003>;
+   };
+
+   cpu4: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x100>;
+   };
+
+   cpu5: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x101>;
+   };
+
+   cpu6: cpu@102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x102>;
+   };
+
+   cpu7: cpu@103 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+ 

[PATCH v3 00/12] Add Basic SoC support for MT6797

2017-03-19 Thread Mars Cheng
This patch set adds basic SoC support for mediatek's first 10-core
chip, X20, also known as MT6797.

- based on 4.11-rc1
- support multiple base address for sysirq
- support common clk framework

Changes since v2:
- prevent uncessary #intpol-bases for mtk-sysirq
- add fast path for mtk-sysirq set_type when introducing multiple bases
- add acked-by and tested-by
- remove wrong usage for timer node

Changes since v1:
- add multiple base addresses support, v1 only allow 2 bases
- clean up clk driver


Kevin-CW Chen (2):
  dt-bindings: arm: mediatek: document clk bindings for MT6797
  clk: mediatek: add clk support for MT6797

Mars Cheng (10):
  dt-bindings: mediatek: multiple bases support for sysirq
  irqchip: mtk-sysirq: extend intpol base to arbitrary number
  irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
  dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform
  arm64: dts: mediatek: add mt6797 support
  soc: mediatek: avoid using fixed spm power status defines
  soc: mediatek: add vdec item for scpsys
  dt-bindings: mediatek: add MT6797 power dt-bindings
  soc: mediatek: add MT6797 scysys support
  arm64: dts: mediatek: add clk and scp nodes for MT6797

 Documentation/devicetree/bindings/arm/mediatek.txt |4 +
 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |3 +-
 .../interrupt-controller/mediatek,sysirq.txt   |   12 +-
 .../devicetree/bindings/serial/mtk-uart.txt|1 +
 .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +-
 arch/arm64/boot/dts/mediatek/Makefile  |1 +
 arch/arm64/boot/dts/mediatek/mt6797-evb.dts|   36 +
 arch/arm64/boot/dts/mediatek/mt6797.dtsi   |  245 +++
 drivers/clk/mediatek/Kconfig   |   32 +
 drivers/clk/mediatek/Makefile  |5 +
 drivers/clk/mediatek/clk-mt6797-img.c  |   76 +++
 drivers/clk/mediatek/clk-mt6797-mm.c   |  136 
 drivers/clk/mediatek/clk-mt6797-vdec.c |   93 +++
 drivers/clk/mediatek/clk-mt6797-venc.c |   78 +++
 drivers/clk/mediatek/clk-mt6797.c  |  716 
 drivers/irqchip/irq-mtk-sysirq.c   |  116 +++-
 drivers/soc/mediatek/mtk-scpsys.c  |  149 +++-
 include/dt-bindings/clock/mt6797-clk.h |  281 
 include/dt-bindings/power/mt6797-power.h   |   30 +
 25 files changed, 1993 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi
 create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797.c
 create mode 100644 include/dt-bindings/clock/mt6797-clk.h
 create mode 100644 include/dt-bindings/power/mt6797-power.h

--
1.7.9.5



[PATCH v3 08/12] soc: mediatek: avoid using fixed spm power status defines

2017-03-19 Thread Mars Cheng
Use variables to replace fixed defines since the offset
of the status of spm power might be different for some chips

Signed-off-by: Mars Cheng 
Signed-off-by: Kevin-CW Chen 
---
 drivers/soc/mediatek/mtk-scpsys.c |   33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index beb7916..eadbf0d 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -107,21 +107,28 @@ struct scp_domain {
struct regulator *supply;
 };
 
+struct scp_ctrl_reg {
+   int pwr_sta_offs;
+   int pwr_sta2nd_offs;
+};
+
 struct scp {
struct scp_domain *domains;
struct genpd_onecell_data pd_data;
struct device *dev;
void __iomem *base;
struct regmap *infracfg;
+   struct scp_ctrl_reg ctrl_reg;
 };
 
 static int scpsys_domain_is_on(struct scp_domain *scpd)
 {
struct scp *scp = scpd->scp;
 
-   u32 status = readl(scp->base + SPM_PWR_STATUS) & scpd->data->sta_mask;
-   u32 status2 = readl(scp->base + SPM_PWR_STATUS_2ND) &
-   scpd->data->sta_mask;
+   u32 status = readl(scp->base + scp->ctrl_reg.pwr_sta_offs) &
+   scpd->data->sta_mask;
+   u32 status2 = readl(scp->base + scp->ctrl_reg.pwr_sta2nd_offs) &
+   scpd->data->sta_mask;
 
/*
 * A domain is on when both status bits are set. If only one is set
@@ -346,7 +353,8 @@ static void init_clks(struct platform_device *pdev, struct 
clk **clk)
 }
 
 static struct scp *init_scp(struct platform_device *pdev,
-   const struct scp_domain_data *scp_domain_data, int num)
+   const struct scp_domain_data *scp_domain_data, int num,
+   struct scp_ctrl_reg *scp_ctrl_reg)
 {
struct genpd_onecell_data *pd_data;
struct resource *res;
@@ -358,6 +366,9 @@ static struct scp *init_scp(struct platform_device *pdev,
if (!scp)
return ERR_PTR(-ENOMEM);
 
+   scp->ctrl_reg.pwr_sta_offs = scp_ctrl_reg->pwr_sta_offs;
+   scp->ctrl_reg.pwr_sta2nd_offs = scp_ctrl_reg->pwr_sta2nd_offs;
+
scp->dev = >dev;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -556,8 +567,13 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 static int __init scpsys_probe_mt2701(struct platform_device *pdev)
 {
struct scp *scp;
+   struct scp_ctrl_reg scp_reg;
 
-   scp = init_scp(pdev, scp_domain_data_mt2701, NUM_DOMAINS_MT2701);
+   scp_reg.pwr_sta_offs = SPM_PWR_STATUS;
+   scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND;
+
+   scp = init_scp(pdev, scp_domain_data_mt2701, NUM_DOMAINS_MT2701,
+  _reg);
if (IS_ERR(scp))
return PTR_ERR(scp);
 
@@ -667,8 +683,13 @@ static int __init scpsys_probe_mt8173(struct 
platform_device *pdev)
struct scp *scp;
struct genpd_onecell_data *pd_data;
int ret;
+   struct scp_ctrl_reg scp_reg;
+
+   scp_reg.pwr_sta_offs = SPM_PWR_STATUS;
+   scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND;
 
-   scp = init_scp(pdev, scp_domain_data_mt8173, NUM_DOMAINS_MT8173);
+   scp = init_scp(pdev, scp_domain_data_mt8173, NUM_DOMAINS_MT8173,
+  _reg);
if (IS_ERR(scp))
return PTR_ERR(scp);
 
-- 
1.7.9.5



[PATCH v3 05/12] arm64: dts: mediatek: add mt6797 support

2017-03-19 Thread Mars Cheng
This adds basic chip support for MT6797 SoC.

Signed-off-by: Mars Cheng 
---
 arch/arm64/boot/dts/mediatek/Makefile   |1 +
 arch/arm64/boot/dts/mediatek/mt6797-evb.dts |   36 ++
 arch/arm64/boot/dts/mediatek/mt6797.dtsi|  182 +++
 3 files changed, 219 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index 9fbfd32..015eb07 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/mediatek/mt6797-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt6797-evb.dts
new file mode 100644
index 000..c79109c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797-evb.dts
@@ -0,0 +1,36 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * This program 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 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.
+ */
+
+/dts-v1/;
+#include "mt6797.dtsi"
+
+/ {
+   model = "MediaTek MT6797 Evaluation Board";
+   compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
+
+   aliases {
+   serial0 = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x1e80>;
+   };
+
+   chosen {};
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
new file mode 100644
index 000..cf4529e
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -0,0 +1,182 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * This program 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 program is distributed in the hope that it will be useful,
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt6797";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x000>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x001>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x002>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x003>;
+   };
+
+   cpu4: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x100>;
+   };
+
+   cpu5: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x101>;
+   };
+
+   cpu6: cpu@102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x102>;
+   };
+
+   cpu7: cpu@103 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x103>;
+   };
+
+   cpu8: cpu@200 {
+

[PATCH v3 00/12] Add Basic SoC support for MT6797

2017-03-19 Thread Mars Cheng
This patch set adds basic SoC support for mediatek's first 10-core
chip, X20, also known as MT6797.

- based on 4.11-rc1
- support multiple base address for sysirq
- support common clk framework

Changes since v2:
- prevent uncessary #intpol-bases for mtk-sysirq
- add fast path for mtk-sysirq set_type when introducing multiple bases
- add acked-by and tested-by
- remove wrong usage for timer node

Changes since v1:
- add multiple base addresses support, v1 only allow 2 bases
- clean up clk driver


Kevin-CW Chen (2):
  dt-bindings: arm: mediatek: document clk bindings for MT6797
  clk: mediatek: add clk support for MT6797

Mars Cheng (10):
  dt-bindings: mediatek: multiple bases support for sysirq
  irqchip: mtk-sysirq: extend intpol base to arbitrary number
  irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
  dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform
  arm64: dts: mediatek: add mt6797 support
  soc: mediatek: avoid using fixed spm power status defines
  soc: mediatek: add vdec item for scpsys
  dt-bindings: mediatek: add MT6797 power dt-bindings
  soc: mediatek: add MT6797 scysys support
  arm64: dts: mediatek: add clk and scp nodes for MT6797

 Documentation/devicetree/bindings/arm/mediatek.txt |4 +
 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt  |1 +
 .../bindings/arm/mediatek/mediatek,infracfg.txt|1 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |1 +
 .../bindings/arm/mediatek/mediatek,topckgen.txt|1 +
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 +
 .../bindings/arm/mediatek/mediatek,vencsys.txt |3 +-
 .../interrupt-controller/mediatek,sysirq.txt   |   12 +-
 .../devicetree/bindings/serial/mtk-uart.txt|1 +
 .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +-
 arch/arm64/boot/dts/mediatek/Makefile  |1 +
 arch/arm64/boot/dts/mediatek/mt6797-evb.dts|   36 +
 arch/arm64/boot/dts/mediatek/mt6797.dtsi   |  245 +++
 drivers/clk/mediatek/Kconfig   |   32 +
 drivers/clk/mediatek/Makefile  |5 +
 drivers/clk/mediatek/clk-mt6797-img.c  |   76 +++
 drivers/clk/mediatek/clk-mt6797-mm.c   |  136 
 drivers/clk/mediatek/clk-mt6797-vdec.c |   93 +++
 drivers/clk/mediatek/clk-mt6797-venc.c |   78 +++
 drivers/clk/mediatek/clk-mt6797.c  |  716 
 drivers/irqchip/irq-mtk-sysirq.c   |  116 +++-
 drivers/soc/mediatek/mtk-scpsys.c  |  149 +++-
 include/dt-bindings/clock/mt6797-clk.h |  281 
 include/dt-bindings/power/mt6797-power.h   |   30 +
 25 files changed, 1993 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6797.dtsi
 create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797.c
 create mode 100644 include/dt-bindings/clock/mt6797-clk.h
 create mode 100644 include/dt-bindings/power/mt6797-power.h

--
1.7.9.5



[PATCH v3 08/12] soc: mediatek: avoid using fixed spm power status defines

2017-03-19 Thread Mars Cheng
Use variables to replace fixed defines since the offset
of the status of spm power might be different for some chips

Signed-off-by: Mars Cheng 
Signed-off-by: Kevin-CW Chen 
---
 drivers/soc/mediatek/mtk-scpsys.c |   33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index beb7916..eadbf0d 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -107,21 +107,28 @@ struct scp_domain {
struct regulator *supply;
 };
 
+struct scp_ctrl_reg {
+   int pwr_sta_offs;
+   int pwr_sta2nd_offs;
+};
+
 struct scp {
struct scp_domain *domains;
struct genpd_onecell_data pd_data;
struct device *dev;
void __iomem *base;
struct regmap *infracfg;
+   struct scp_ctrl_reg ctrl_reg;
 };
 
 static int scpsys_domain_is_on(struct scp_domain *scpd)
 {
struct scp *scp = scpd->scp;
 
-   u32 status = readl(scp->base + SPM_PWR_STATUS) & scpd->data->sta_mask;
-   u32 status2 = readl(scp->base + SPM_PWR_STATUS_2ND) &
-   scpd->data->sta_mask;
+   u32 status = readl(scp->base + scp->ctrl_reg.pwr_sta_offs) &
+   scpd->data->sta_mask;
+   u32 status2 = readl(scp->base + scp->ctrl_reg.pwr_sta2nd_offs) &
+   scpd->data->sta_mask;
 
/*
 * A domain is on when both status bits are set. If only one is set
@@ -346,7 +353,8 @@ static void init_clks(struct platform_device *pdev, struct 
clk **clk)
 }
 
 static struct scp *init_scp(struct platform_device *pdev,
-   const struct scp_domain_data *scp_domain_data, int num)
+   const struct scp_domain_data *scp_domain_data, int num,
+   struct scp_ctrl_reg *scp_ctrl_reg)
 {
struct genpd_onecell_data *pd_data;
struct resource *res;
@@ -358,6 +366,9 @@ static struct scp *init_scp(struct platform_device *pdev,
if (!scp)
return ERR_PTR(-ENOMEM);
 
+   scp->ctrl_reg.pwr_sta_offs = scp_ctrl_reg->pwr_sta_offs;
+   scp->ctrl_reg.pwr_sta2nd_offs = scp_ctrl_reg->pwr_sta2nd_offs;
+
scp->dev = >dev;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -556,8 +567,13 @@ static void mtk_register_power_domains(struct 
platform_device *pdev,
 static int __init scpsys_probe_mt2701(struct platform_device *pdev)
 {
struct scp *scp;
+   struct scp_ctrl_reg scp_reg;
 
-   scp = init_scp(pdev, scp_domain_data_mt2701, NUM_DOMAINS_MT2701);
+   scp_reg.pwr_sta_offs = SPM_PWR_STATUS;
+   scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND;
+
+   scp = init_scp(pdev, scp_domain_data_mt2701, NUM_DOMAINS_MT2701,
+  _reg);
if (IS_ERR(scp))
return PTR_ERR(scp);
 
@@ -667,8 +683,13 @@ static int __init scpsys_probe_mt8173(struct 
platform_device *pdev)
struct scp *scp;
struct genpd_onecell_data *pd_data;
int ret;
+   struct scp_ctrl_reg scp_reg;
+
+   scp_reg.pwr_sta_offs = SPM_PWR_STATUS;
+   scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND;
 
-   scp = init_scp(pdev, scp_domain_data_mt8173, NUM_DOMAINS_MT8173);
+   scp = init_scp(pdev, scp_domain_data_mt8173, NUM_DOMAINS_MT8173,
+  _reg);
if (IS_ERR(scp))
return PTR_ERR(scp);
 
-- 
1.7.9.5



[PATCH v3 09/12] soc: mediatek: add vdec item for scpsys

2017-03-19 Thread Mars Cheng
for some chips, there is vdec item in scpsys, this patch adds it.

Signed-off-by: Mars Cheng 
---
 drivers/soc/mediatek/mtk-scpsys.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index eadbf0d..a8ba800 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -71,6 +71,7 @@ enum clk_id {
CLK_VENC,
CLK_VENC_LT,
CLK_ETHIF,
+   CLK_VDEC,
CLK_MAX,
 };
 
@@ -81,6 +82,7 @@ enum clk_id {
"venc",
"venc_lt",
"ethif",
+   "vdec",
NULL,
 };
 
-- 
1.7.9.5



[PATCH v3 09/12] soc: mediatek: add vdec item for scpsys

2017-03-19 Thread Mars Cheng
for some chips, there is vdec item in scpsys, this patch adds it.

Signed-off-by: Mars Cheng 
---
 drivers/soc/mediatek/mtk-scpsys.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index eadbf0d..a8ba800 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -71,6 +71,7 @@ enum clk_id {
CLK_VENC,
CLK_VENC_LT,
CLK_ETHIF,
+   CLK_VDEC,
CLK_MAX,
 };
 
@@ -81,6 +82,7 @@ enum clk_id {
"venc",
"venc_lt",
"ethif",
+   "vdec",
NULL,
 };
 
-- 
1.7.9.5



[PATCH v3 12/12] arm64: dts: mediatek: add clk and scp nodes for MT6797

2017-03-19 Thread Mars Cheng
This adds clk and scp nodes for MT6797

Signed-off-by: Mars Cheng 
---
 arch/arm64/boot/dts/mediatek/mt6797.dtsi |   71 --
 1 file changed, 67 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index cf4529e..3512c8e 100644
--- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -11,6 +11,8 @@
  * GNU General Public License for more details.
  */
 
+#include 
+#include 
 #include 
 #include 
 
@@ -123,6 +125,35 @@
 ;
};
 
+   topckgen: topckgen@1000 {
+   compatible = "mediatek,mt6797-topckgen";
+   reg = <0 0x1000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   infrasys: infracfg_ao@10001000 {
+   compatible = "mediatek,mt6797-infracfg", "syscon";
+   reg = <0 0x10001000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   scpsys: scpsys@10006000 {
+   compatible = "mediatek,mt6797-scpsys";
+   #power-domain-cells = <1>;
+   reg = <0 0x10006000 0 0x1000>;
+   clocks = < CLK_TOP_MUX_MFG>,
+< CLK_TOP_MUX_MM>,
+< CLK_TOP_MUX_VDEC>;
+   clock-names = "mfg", "mm", "vdec";
+   infracfg = <>;
+   };
+
+   apmixedsys: apmixed@1000c000 {
+   compatible = "mediatek,mt6797-apmixedsys";
+   reg = <0 0x1000c000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt6797-sysirq",
 "mediatek,mt6577-sysirq";
@@ -138,7 +169,9 @@
 "mediatek,mt6577-uart";
reg = <0 0x11002000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART0>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -147,7 +180,9 @@
 "mediatek,mt6577-uart";
reg = <0 0x11003000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART1>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -156,7 +191,9 @@
 "mediatek,mt6577-uart";
reg = <0 0x11004000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART2>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -165,10 +202,36 @@
 "mediatek,mt6577-uart";
reg = <0 0x11005000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART3>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
+   mmsys: mmsys_config@1400 {
+   compatible = "mediatek,mt6797-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   imgsys: imgsys_config@1500  {
+   compatible = "mediatek,mt6797-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vdecsys: vdec_gcon@1600 {
+   compatible = "mediatek,mt6797-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1>;
+   #clock-cells = <1>;
+   };
+
+   vencsys: venc_gcon@1700 {
+   compatible = "mediatek,mt6797-vencsys", "syscon";
+   reg = <0 0x1700 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
gic: interrupt-controller@1900 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
-- 
1.7.9.5



[PATCH v3 04/12] dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform

2017-03-19 Thread Mars Cheng
This adds dt-binding documentation for Mediatek MT6797. Only
include very basic items, gic, uart timer and cpu.

Signed-off-by: Mars Cheng 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |4 
 .../interrupt-controller/mediatek,sysirq.txt   |1 +
 .../devicetree/bindings/serial/mtk-uart.txt|1 +
 3 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index c860b24..2d3344d 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -12,6 +12,7 @@ compatible: Must contain one of
"mediatek,mt6592"
"mediatek,mt6755"
"mediatek,mt6795"
+   "mediatek,mt6797"
"mediatek,mt7623"
"mediatek,mt8127"
"mediatek,mt8135"
@@ -38,6 +39,9 @@ Supported boards:
 - Evaluation board for MT6795(Helio X10):
 Required root node properties:
   - compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
+- Evaluation board for MT6797(Helio X20):
+Required root node properties:
+  - compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
 - Evaluation board for MT7623:
 Required root node properties:
   - compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 40bf9b9..04e162a 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -9,6 +9,7 @@ Required properties:
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6795-sysirq"
+   "mediatek,mt6797-sysirq"
"mediatek,mt6755-sysirq"
"mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq"
diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt 
b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index 0015c72..5b8513d 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -8,6 +8,7 @@ Required properties:
   * "mediatek,mt6589-uart" for MT6589 compatible UARTS
   * "mediatek,mt6755-uart" for MT6755 compatible UARTS
   * "mediatek,mt6795-uart" for MT6795 compatible UARTS
+  * "mediatek,mt6797-uart" for MT6797 compatible UARTS
   * "mediatek,mt7623-uart" for MT7623 compatible UARTS
   * "mediatek,mt8127-uart" for MT8127 compatible UARTS
   * "mediatek,mt8135-uart" for MT8135 compatible UARTS
-- 
1.7.9.5



[PATCH v3 04/12] dt-bindings: mediatek: Add bindings for mediatek MT6797 Platform

2017-03-19 Thread Mars Cheng
This adds dt-binding documentation for Mediatek MT6797. Only
include very basic items, gic, uart timer and cpu.

Signed-off-by: Mars Cheng 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |4 
 .../interrupt-controller/mediatek,sysirq.txt   |1 +
 .../devicetree/bindings/serial/mtk-uart.txt|1 +
 3 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index c860b24..2d3344d 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -12,6 +12,7 @@ compatible: Must contain one of
"mediatek,mt6592"
"mediatek,mt6755"
"mediatek,mt6795"
+   "mediatek,mt6797"
"mediatek,mt7623"
"mediatek,mt8127"
"mediatek,mt8135"
@@ -38,6 +39,9 @@ Supported boards:
 - Evaluation board for MT6795(Helio X10):
 Required root node properties:
   - compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
+- Evaluation board for MT6797(Helio X20):
+Required root node properties:
+  - compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
 - Evaluation board for MT7623:
 Required root node properties:
   - compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 40bf9b9..04e162a 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -9,6 +9,7 @@ Required properties:
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6795-sysirq"
+   "mediatek,mt6797-sysirq"
"mediatek,mt6755-sysirq"
"mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq"
diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt 
b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index 0015c72..5b8513d 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -8,6 +8,7 @@ Required properties:
   * "mediatek,mt6589-uart" for MT6589 compatible UARTS
   * "mediatek,mt6755-uart" for MT6755 compatible UARTS
   * "mediatek,mt6795-uart" for MT6795 compatible UARTS
+  * "mediatek,mt6797-uart" for MT6797 compatible UARTS
   * "mediatek,mt7623-uart" for MT7623 compatible UARTS
   * "mediatek,mt8127-uart" for MT8127 compatible UARTS
   * "mediatek,mt8135-uart" for MT8135 compatible UARTS
-- 
1.7.9.5



[PATCH v3 12/12] arm64: dts: mediatek: add clk and scp nodes for MT6797

2017-03-19 Thread Mars Cheng
This adds clk and scp nodes for MT6797

Signed-off-by: Mars Cheng 
---
 arch/arm64/boot/dts/mediatek/mt6797.dtsi |   71 --
 1 file changed, 67 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index cf4529e..3512c8e 100644
--- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -11,6 +11,8 @@
  * GNU General Public License for more details.
  */
 
+#include 
+#include 
 #include 
 #include 
 
@@ -123,6 +125,35 @@
 ;
};
 
+   topckgen: topckgen@1000 {
+   compatible = "mediatek,mt6797-topckgen";
+   reg = <0 0x1000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   infrasys: infracfg_ao@10001000 {
+   compatible = "mediatek,mt6797-infracfg", "syscon";
+   reg = <0 0x10001000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   scpsys: scpsys@10006000 {
+   compatible = "mediatek,mt6797-scpsys";
+   #power-domain-cells = <1>;
+   reg = <0 0x10006000 0 0x1000>;
+   clocks = < CLK_TOP_MUX_MFG>,
+< CLK_TOP_MUX_MM>,
+< CLK_TOP_MUX_VDEC>;
+   clock-names = "mfg", "mm", "vdec";
+   infracfg = <>;
+   };
+
+   apmixedsys: apmixed@1000c000 {
+   compatible = "mediatek,mt6797-apmixedsys";
+   reg = <0 0x1000c000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt6797-sysirq",
 "mediatek,mt6577-sysirq";
@@ -138,7 +169,9 @@
 "mediatek,mt6577-uart";
reg = <0 0x11002000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART0>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -147,7 +180,9 @@
 "mediatek,mt6577-uart";
reg = <0 0x11003000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART1>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -156,7 +191,9 @@
 "mediatek,mt6577-uart";
reg = <0 0x11004000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART2>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -165,10 +202,36 @@
 "mediatek,mt6577-uart";
reg = <0 0x11005000 0 0x400>;
interrupts = ;
-   clocks = <>;
+   clocks = < CLK_INFRA_UART3>,
+< CLK_INFRA_AP_DMA>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
+   mmsys: mmsys_config@1400 {
+   compatible = "mediatek,mt6797-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   imgsys: imgsys_config@1500  {
+   compatible = "mediatek,mt6797-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vdecsys: vdec_gcon@1600 {
+   compatible = "mediatek,mt6797-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1>;
+   #clock-cells = <1>;
+   };
+
+   vencsys: venc_gcon@1700 {
+   compatible = "mediatek,mt6797-vencsys", "syscon";
+   reg = <0 0x1700 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
gic: interrupt-controller@1900 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
-- 
1.7.9.5



[PATCH v3 11/12] soc: mediatek: add MT6797 scysys support

2017-03-19 Thread Mars Cheng
This adds scysys support for MT6797

Signed-off-by: Mars Cheng 
Signed-off-by: Kevin-CW Chen 
---
 drivers/soc/mediatek/mtk-scpsys.c|  114 ++
 include/dt-bindings/power/mt6797-power.h |   30 
 2 files changed, 144 insertions(+)
 create mode 100644 include/dt-bindings/power/mt6797-power.h

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index a8ba800..fc7bf95 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -585,6 +586,116 @@ static int __init scpsys_probe_mt2701(struct 
platform_device *pdev)
 }
 
 /*
+ * MT6797 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt6797[] = {
+   [MT6797_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = BIT(7),
+   .ctl_offs = 0x300,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_VDEC},
+   },
+   [MT6797_POWER_DOMAIN_VENC] = {
+   .name = "venc",
+   .sta_mask = BIT(21),
+   .ctl_offs = 0x304,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_NONE},
+   },
+   [MT6797_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = BIT(5),
+   .ctl_offs = 0x308,
+   .sram_pdn_bits = GENMASK(9, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   .clk_id = {CLK_NONE},
+   },
+   [MT6797_POWER_DOMAIN_MM] = {
+   .name = "mm",
+   .sta_mask = BIT(3),
+   .ctl_offs = 0x30C,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .bus_prot_mask = (BIT(1) | BIT(2)),
+   },
+   [MT6797_POWER_DOMAIN_AUDIO] = {
+   .name = "audio",
+   .sta_mask = BIT(24),
+   .ctl_offs = 0x314,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_NONE},
+   },
+   [MT6797_POWER_DOMAIN_MFG_ASYNC] = {
+   .name = "mfg_async",
+   .sta_mask = BIT(13),
+   .ctl_offs = 0x334,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   .clk_id = {CLK_MFG},
+   },
+   [MT6797_POWER_DOMAIN_MJC] = {
+   .name = "mjc",
+   .sta_mask = BIT(20),
+   .ctl_offs = 0x310,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_NONE},
+   },
+};
+
+#define NUM_DOMAINS_MT6797 ARRAY_SIZE(scp_domain_data_mt6797)
+#define SPM_PWR_STATUS_MT6797  0x0180
+#define SPM_PWR_STATUS_2ND_MT6797  0x0184
+
+static int __init scpsys_probe_mt6797(struct platform_device *pdev)
+{
+   struct scp *scp;
+   struct genpd_onecell_data *pd_data;
+   int ret;
+   struct scp_ctrl_reg scp_reg;
+
+   scp_reg.pwr_sta_offs = SPM_PWR_STATUS_MT6797;
+   scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797;
+
+   scp = init_scp(pdev, scp_domain_data_mt6797, NUM_DOMAINS_MT6797,
+  _reg);
+   if (IS_ERR(scp))
+   return PTR_ERR(scp);
+
+   mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT6797);
+
+   pd_data = >pd_data;
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_VDEC]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_ISP]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_VENC]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_MJC]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   return 0;
+}
+
+/*
  * MT8173 power domain support
  */
 
@@ -721,6 +832,9 @@ static int __init scpsys_probe_mt8173(struct 
platform_device *pdev)
.compatible = 

[PATCH v3 10/12] dt-bindings: mediatek: add MT6797 power dt-bindings

2017-03-19 Thread Mars Cheng
This adds scpsys dt-bindings for MT6797

Signed-off-by: Mars Cheng 
Signed-off-by: Kevin-CW Chen 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 16fe94d..b1d165b 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,11 +9,14 @@ domain control.
 
 The driver implements the Generic PM domain bindings described in
 power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
+- include/dt-bindings/power/mt8173-power.h
+- include/dt-bindings/power/mt6797-power.h
+- include/dt-bindings/power/mt2701-power.h
 
 Required properties:
 - compatible: Should be one of:
- "mediatek,mt2701-scpsys"
+   - "mediatek,mt6797-scpsys"
- "mediatek,mt8173-scpsys"
 - #power-domain-cells: Must be 1
 - reg: Address range of the SCPSYS unit
@@ -22,6 +25,7 @@ Required properties:
   These are clocks which hardware needs to be
   enabled before enabling certain power domains.
Required clocks for MT2701: "mm", "mfg", "ethif"
+   Required clocks for MT6797: "mm", "mfg", "vdec"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
 
 Optional properties:
-- 
1.7.9.5



[PATCH v3 11/12] soc: mediatek: add MT6797 scysys support

2017-03-19 Thread Mars Cheng
This adds scysys support for MT6797

Signed-off-by: Mars Cheng 
Signed-off-by: Kevin-CW Chen 
---
 drivers/soc/mediatek/mtk-scpsys.c|  114 ++
 include/dt-bindings/power/mt6797-power.h |   30 
 2 files changed, 144 insertions(+)
 create mode 100644 include/dt-bindings/power/mt6797-power.h

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index a8ba800..fc7bf95 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #define SPM_VDE_PWR_CON0x0210
@@ -585,6 +586,116 @@ static int __init scpsys_probe_mt2701(struct 
platform_device *pdev)
 }
 
 /*
+ * MT6797 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt6797[] = {
+   [MT6797_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
+   .sta_mask = BIT(7),
+   .ctl_offs = 0x300,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_VDEC},
+   },
+   [MT6797_POWER_DOMAIN_VENC] = {
+   .name = "venc",
+   .sta_mask = BIT(21),
+   .ctl_offs = 0x304,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_NONE},
+   },
+   [MT6797_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = BIT(5),
+   .ctl_offs = 0x308,
+   .sram_pdn_bits = GENMASK(9, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   .clk_id = {CLK_NONE},
+   },
+   [MT6797_POWER_DOMAIN_MM] = {
+   .name = "mm",
+   .sta_mask = BIT(3),
+   .ctl_offs = 0x30C,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   .bus_prot_mask = (BIT(1) | BIT(2)),
+   },
+   [MT6797_POWER_DOMAIN_AUDIO] = {
+   .name = "audio",
+   .sta_mask = BIT(24),
+   .ctl_offs = 0x314,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   .clk_id = {CLK_NONE},
+   },
+   [MT6797_POWER_DOMAIN_MFG_ASYNC] = {
+   .name = "mfg_async",
+   .sta_mask = BIT(13),
+   .ctl_offs = 0x334,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   .clk_id = {CLK_MFG},
+   },
+   [MT6797_POWER_DOMAIN_MJC] = {
+   .name = "mjc",
+   .sta_mask = BIT(20),
+   .ctl_offs = 0x310,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_NONE},
+   },
+};
+
+#define NUM_DOMAINS_MT6797 ARRAY_SIZE(scp_domain_data_mt6797)
+#define SPM_PWR_STATUS_MT6797  0x0180
+#define SPM_PWR_STATUS_2ND_MT6797  0x0184
+
+static int __init scpsys_probe_mt6797(struct platform_device *pdev)
+{
+   struct scp *scp;
+   struct genpd_onecell_data *pd_data;
+   int ret;
+   struct scp_ctrl_reg scp_reg;
+
+   scp_reg.pwr_sta_offs = SPM_PWR_STATUS_MT6797;
+   scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797;
+
+   scp = init_scp(pdev, scp_domain_data_mt6797, NUM_DOMAINS_MT6797,
+  _reg);
+   if (IS_ERR(scp))
+   return PTR_ERR(scp);
+
+   mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT6797);
+
+   pd_data = >pd_data;
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_VDEC]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_ISP]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_VENC]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   ret = pm_genpd_add_subdomain(pd_data->domains[MT6797_POWER_DOMAIN_MM],
+   pd_data->domains[MT6797_POWER_DOMAIN_MJC]);
+   if (ret && IS_ENABLED(CONFIG_PM))
+   dev_err(>dev, "Failed to add subdomain: %d\n", ret);
+
+   return 0;
+}
+
+/*
  * MT8173 power domain support
  */
 
@@ -721,6 +832,9 @@ static int __init scpsys_probe_mt8173(struct 
platform_device *pdev)
.compatible = "mediatek,mt2701-scpsys",
.data = 

[PATCH v3 10/12] dt-bindings: mediatek: add MT6797 power dt-bindings

2017-03-19 Thread Mars Cheng
This adds scpsys dt-bindings for MT6797

Signed-off-by: Mars Cheng 
Signed-off-by: Kevin-CW Chen 
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt|6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt 
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 16fe94d..b1d165b 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,11 +9,14 @@ domain control.
 
 The driver implements the Generic PM domain bindings described in
 power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
+- include/dt-bindings/power/mt8173-power.h
+- include/dt-bindings/power/mt6797-power.h
+- include/dt-bindings/power/mt2701-power.h
 
 Required properties:
 - compatible: Should be one of:
- "mediatek,mt2701-scpsys"
+   - "mediatek,mt6797-scpsys"
- "mediatek,mt8173-scpsys"
 - #power-domain-cells: Must be 1
 - reg: Address range of the SCPSYS unit
@@ -22,6 +25,7 @@ Required properties:
   These are clocks which hardware needs to be
   enabled before enabling certain power domains.
Required clocks for MT2701: "mm", "mfg", "ethif"
+   Required clocks for MT6797: "mm", "mfg", "vdec"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
 
 Optional properties:
-- 
1.7.9.5



[PATCH v3 03/12] irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

2017-03-19 Thread Mars Cheng
This prevent unnecessary visibility when configuring trigger type

Signed-off-by: Mars Cheng 
---
 drivers/irqchip/irq-mtk-sysirq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index 9ba969c..eeac512 100644
--- a/drivers/irqchip/irq-mtk-sysirq.c
+++ b/drivers/irqchip/irq-mtk-sysirq.c
@@ -57,7 +57,7 @@ static int mtk_sysirq_set_type(struct irq_data *data, 
unsigned int type)
value &= ~(1 << offset);
}
 
-   writel(value, base + reg_index * 4);
+   writel_relaxed(value, base + reg_index * 4);
 
data = data->parent_data;
ret = data->chip->irq_set_type(data, type);
-- 
1.7.9.5



[PATCH v3 07/12] clk: mediatek: add clk support for MT6797

2017-03-19 Thread Mars Cheng
From: Kevin-CW Chen 

Add MT6797 clock support, include topckgen, apmixedsys, infracfg
and subsystem clocks

Signed-off-by: Kevin-CW Chen 
Signed-off-by: Mars Cheng 
Tested-by: Matthias Brugger 
---
 drivers/clk/mediatek/Kconfig   |   32 ++
 drivers/clk/mediatek/Makefile  |5 +
 drivers/clk/mediatek/clk-mt6797-img.c  |   76 
 drivers/clk/mediatek/clk-mt6797-mm.c   |  136 ++
 drivers/clk/mediatek/clk-mt6797-vdec.c |   93 +
 drivers/clk/mediatek/clk-mt6797-venc.c |   78 
 drivers/clk/mediatek/clk-mt6797.c  |  716 
 include/dt-bindings/clock/mt6797-clk.h |  281 +
 8 files changed, 1417 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797.c
 create mode 100644 include/dt-bindings/clock/mt6797-clk.h

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index a01ef78..28739a9 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,38 @@ config COMMON_CLK_MT2701_BDPSYS
---help---
  This driver supports Mediatek MT2701 bdpsys clocks.
 
+config COMMON_CLK_MT6797
+   bool "Clock driver for Mediatek MT6797"
+   depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK && ARM64
+   ---help---
+ This driver supports Mediatek MT6797 basic clocks.
+
+config COMMON_CLK_MT6797_MMSYS
+   bool "Clock driver for Mediatek MT6797 mmsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 mmsys clocks.
+
+config COMMON_CLK_MT6797_IMGSYS
+   bool "Clock driver for Mediatek MT6797 imgsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 imgsys clocks.
+
+config COMMON_CLK_MT6797_VDECSYS
+   bool "Clock driver for Mediatek MT6797 vdecsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 vdecsys clocks.
+
+config COMMON_CLK_MT6797_VENCSYS
+   bool "Clock driver for Mediatek MT6797 vencsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 vencsys clocks.
+
 config COMMON_CLK_MT8135
bool "Clock driver for Mediatek MT8135"
depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 19ae7ef..5c3afb8 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,5 +1,10 @@
 obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
+obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
+obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
+obj-$(CONFIG_COMMON_CLK_MT6797_VDECSYS) += clk-mt6797-vdec.o
+obj-$(CONFIG_COMMON_CLK_MT6797_VENCSYS) += clk-mt6797-venc.o
 obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
 obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
 obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
diff --git a/drivers/clk/mediatek/clk-mt6797-img.c 
b/drivers/clk/mediatek/clk-mt6797-img.c
new file mode 100644
index 000..94cc480
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt6797-img.c
@@ -0,0 +1,76 @@
+/* Copyright (c) 2017 MediaTek Inc.
+ * Author: Kevin Chen 
+ *
+ * This program 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 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 "clk-mtk.h"
+#include "clk-gate.h"
+
+static const struct mtk_gate_regs img_cg_regs = {
+   .set_ofs = 0x0004,
+   .clr_ofs = 0x0008,
+   .sta_ofs = 0x,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,   \
+   .shift = _shift,\
+   .ops = _clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate img_clks[] = {
+   GATE_IMG(CLK_IMG_FDVT, "img_fdvt", "mm_sel", 11),
+   

[PATCH v3 03/12] irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

2017-03-19 Thread Mars Cheng
This prevent unnecessary visibility when configuring trigger type

Signed-off-by: Mars Cheng 
---
 drivers/irqchip/irq-mtk-sysirq.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
index 9ba969c..eeac512 100644
--- a/drivers/irqchip/irq-mtk-sysirq.c
+++ b/drivers/irqchip/irq-mtk-sysirq.c
@@ -57,7 +57,7 @@ static int mtk_sysirq_set_type(struct irq_data *data, 
unsigned int type)
value &= ~(1 << offset);
}
 
-   writel(value, base + reg_index * 4);
+   writel_relaxed(value, base + reg_index * 4);
 
data = data->parent_data;
ret = data->chip->irq_set_type(data, type);
-- 
1.7.9.5



[PATCH v3 07/12] clk: mediatek: add clk support for MT6797

2017-03-19 Thread Mars Cheng
From: Kevin-CW Chen 

Add MT6797 clock support, include topckgen, apmixedsys, infracfg
and subsystem clocks

Signed-off-by: Kevin-CW Chen 
Signed-off-by: Mars Cheng 
Tested-by: Matthias Brugger 
---
 drivers/clk/mediatek/Kconfig   |   32 ++
 drivers/clk/mediatek/Makefile  |5 +
 drivers/clk/mediatek/clk-mt6797-img.c  |   76 
 drivers/clk/mediatek/clk-mt6797-mm.c   |  136 ++
 drivers/clk/mediatek/clk-mt6797-vdec.c |   93 +
 drivers/clk/mediatek/clk-mt6797-venc.c |   78 
 drivers/clk/mediatek/clk-mt6797.c  |  716 
 include/dt-bindings/clock/mt6797-clk.h |  281 +
 8 files changed, 1417 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt6797-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt6797.c
 create mode 100644 include/dt-bindings/clock/mt6797-clk.h

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index a01ef78..28739a9 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,38 @@ config COMMON_CLK_MT2701_BDPSYS
---help---
  This driver supports Mediatek MT2701 bdpsys clocks.
 
+config COMMON_CLK_MT6797
+   bool "Clock driver for Mediatek MT6797"
+   depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK && ARM64
+   ---help---
+ This driver supports Mediatek MT6797 basic clocks.
+
+config COMMON_CLK_MT6797_MMSYS
+   bool "Clock driver for Mediatek MT6797 mmsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 mmsys clocks.
+
+config COMMON_CLK_MT6797_IMGSYS
+   bool "Clock driver for Mediatek MT6797 imgsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 imgsys clocks.
+
+config COMMON_CLK_MT6797_VDECSYS
+   bool "Clock driver for Mediatek MT6797 vdecsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 vdecsys clocks.
+
+config COMMON_CLK_MT6797_VENCSYS
+   bool "Clock driver for Mediatek MT6797 vencsys"
+   depends on COMMON_CLK_MT6797
+   ---help---
+ This driver supports Mediatek MT6797 vencsys clocks.
+
 config COMMON_CLK_MT8135
bool "Clock driver for Mediatek MT8135"
depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 19ae7ef..5c3afb8 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,5 +1,10 @@
 obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
+obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
+obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
+obj-$(CONFIG_COMMON_CLK_MT6797_VDECSYS) += clk-mt6797-vdec.o
+obj-$(CONFIG_COMMON_CLK_MT6797_VENCSYS) += clk-mt6797-venc.o
 obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
 obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
 obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
diff --git a/drivers/clk/mediatek/clk-mt6797-img.c 
b/drivers/clk/mediatek/clk-mt6797-img.c
new file mode 100644
index 000..94cc480
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt6797-img.c
@@ -0,0 +1,76 @@
+/* Copyright (c) 2017 MediaTek Inc.
+ * Author: Kevin Chen 
+ *
+ * This program 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 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 "clk-mtk.h"
+#include "clk-gate.h"
+
+static const struct mtk_gate_regs img_cg_regs = {
+   .set_ofs = 0x0004,
+   .clr_ofs = 0x0008,
+   .sta_ofs = 0x,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,   \
+   .shift = _shift,\
+   .ops = _clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate img_clks[] = {
+   GATE_IMG(CLK_IMG_FDVT, "img_fdvt", "mm_sel", 11),
+   GATE_IMG(CLK_IMG_DPE, "img_dpe", "mm_sel", 10),
+   GATE_IMG(CLK_IMG_DIP, "img_dip", "mm_sel", 6),
+   GATE_IMG(CLK_IMG_LARB6, 

[PATCH v3 01/12] dt-bindings: mediatek: multiple bases support for sysirq

2017-03-19 Thread Mars Cheng
This describes how to specify multiple base addresses for sysirq
in mediatek platforms.

Signed-off-by: Mars Cheng 
---
 .../interrupt-controller/mediatek,sysirq.txt   |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 9d1d72c..40bf9b9 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -21,13 +21,16 @@ Required properties:
 - interrupt-parent: phandle of irq parent for sysirq. The parent must
   use the same interrupt-cells format as GIC.
 - reg: Physical base address of the intpol registers and length of memory
-  mapped region.
+  mapped region. Could be multiple bases here. Ex: mt6797 needs 2 reg, others
+  need 1.
 
 Example:
-   sysirq: interrupt-controller@10200100 {
-   compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq";
+   sysirq: intpol-controller@10200620 {
+   compatible = "mediatek,mt6797-sysirq",
+"mediatek,mt6577-sysirq";
interrupt-controller;
#interrupt-cells = <3>;
interrupt-parent = <>;
-   reg = <0 0x10200100 0 0x1c>;
+   reg = <0 0x10220620 0 0x20>,
+ <0 0x10220690 0 0x10>;
};
-- 
1.7.9.5



[PATCH v3 01/12] dt-bindings: mediatek: multiple bases support for sysirq

2017-03-19 Thread Mars Cheng
This describes how to specify multiple base addresses for sysirq
in mediatek platforms.

Signed-off-by: Mars Cheng 
---
 .../interrupt-controller/mediatek,sysirq.txt   |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt 
b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 9d1d72c..40bf9b9 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -21,13 +21,16 @@ Required properties:
 - interrupt-parent: phandle of irq parent for sysirq. The parent must
   use the same interrupt-cells format as GIC.
 - reg: Physical base address of the intpol registers and length of memory
-  mapped region.
+  mapped region. Could be multiple bases here. Ex: mt6797 needs 2 reg, others
+  need 1.
 
 Example:
-   sysirq: interrupt-controller@10200100 {
-   compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq";
+   sysirq: intpol-controller@10200620 {
+   compatible = "mediatek,mt6797-sysirq",
+"mediatek,mt6577-sysirq";
interrupt-controller;
#interrupt-cells = <3>;
interrupt-parent = <>;
-   reg = <0 0x10200100 0 0x1c>;
+   reg = <0 0x10220620 0 0x20>,
+ <0 0x10220690 0 0x10>;
};
-- 
1.7.9.5



Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

2017-03-19 Thread Russell King - ARM Linux
On Thu, Mar 09, 2017 at 08:53:18PM -0800, Steve Longerbeam wrote:
> From: Philipp Zabel 
> 
> The csi_try_crop call in set_fmt should compare the cropping rectangle
> to the currently set input format, not to the previous input format.

Are we really sure that the cropping support is implemented correctly?

I came across this while looking at what we're doing with the
V4L2_SEL_FLAG_KEEP_CONFIG flag.

Documentation/media/uapi/v4l/dev-subdev.rst defines the behaviour of
the user API, and "Order of configuration and format propagation" says:

  The coordinates to a step always refer to the actual size of the
  previous step. The exception to this rule is the source compose
  rectangle, which refers to the sink compose bounds rectangle --- if it
  is supported by the hardware.
  
  1. Sink pad format. The user configures the sink pad format. This format
 defines the parameters of the image the entity receives through the
 pad for further processing.
  
  2. Sink pad actual crop selection. The sink pad crop defines the crop
 performed to the sink pad format.
  
  3. Sink pad actual compose selection. The size of the sink pad compose
 rectangle defines the scaling ratio compared to the size of the sink
 pad crop rectangle. The location of the compose rectangle specifies
 the location of the actual sink compose rectangle in the sink compose
 bounds rectangle.
  
  4. Source pad actual crop selection. Crop on the source pad defines crop
 performed to the image in the sink compose bounds rectangle.
  
  5. Source pad format. The source pad format defines the output pixel
 format of the subdev, as well as the other parameters with the
 exception of the image width and height. Width and height are defined
 by the size of the source pad actual crop selection.
  
  Accessing any of the above rectangles not supported by the subdev will
  return ``EINVAL``. Any rectangle referring to a previous unsupported
  rectangle coordinates will instead refer to the previous supported
  rectangle. For example, if sink crop is not supported, the compose
  selection will refer to the sink pad format dimensions instead.

Note step 3 above: scaling is defined by the ratio of the _sink_ crop
rectangle to the _sink_ compose rectangle.

So, lets say that the camera produces a 1280x720 image, and the sink
pad format is configured with 1280x720.  That's step 1.

The sink crop operates within that rectangle, cropping it to an area.
Let's say we're only interested in its centre, so we'd chose 640x360
with the top-left as 320,180.  This is step 2.

Then, if we want to down-scale by a factor of two, we'd set the sink
compose selection to 320x180.

This seems to be at odds with how the scaling is done in CSI at
present: the selection implementations all reject attempts to
configure the sink pad, instead only supporting crop rectangles on
the source, and we use the source crop rectangle to define the
down-scaling.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt

2017-03-19 Thread Russell King - ARM Linux
On Thu, Mar 09, 2017 at 08:53:18PM -0800, Steve Longerbeam wrote:
> From: Philipp Zabel 
> 
> The csi_try_crop call in set_fmt should compare the cropping rectangle
> to the currently set input format, not to the previous input format.

Are we really sure that the cropping support is implemented correctly?

I came across this while looking at what we're doing with the
V4L2_SEL_FLAG_KEEP_CONFIG flag.

Documentation/media/uapi/v4l/dev-subdev.rst defines the behaviour of
the user API, and "Order of configuration and format propagation" says:

  The coordinates to a step always refer to the actual size of the
  previous step. The exception to this rule is the source compose
  rectangle, which refers to the sink compose bounds rectangle --- if it
  is supported by the hardware.
  
  1. Sink pad format. The user configures the sink pad format. This format
 defines the parameters of the image the entity receives through the
 pad for further processing.
  
  2. Sink pad actual crop selection. The sink pad crop defines the crop
 performed to the sink pad format.
  
  3. Sink pad actual compose selection. The size of the sink pad compose
 rectangle defines the scaling ratio compared to the size of the sink
 pad crop rectangle. The location of the compose rectangle specifies
 the location of the actual sink compose rectangle in the sink compose
 bounds rectangle.
  
  4. Source pad actual crop selection. Crop on the source pad defines crop
 performed to the image in the sink compose bounds rectangle.
  
  5. Source pad format. The source pad format defines the output pixel
 format of the subdev, as well as the other parameters with the
 exception of the image width and height. Width and height are defined
 by the size of the source pad actual crop selection.
  
  Accessing any of the above rectangles not supported by the subdev will
  return ``EINVAL``. Any rectangle referring to a previous unsupported
  rectangle coordinates will instead refer to the previous supported
  rectangle. For example, if sink crop is not supported, the compose
  selection will refer to the sink pad format dimensions instead.

Note step 3 above: scaling is defined by the ratio of the _sink_ crop
rectangle to the _sink_ compose rectangle.

So, lets say that the camera produces a 1280x720 image, and the sink
pad format is configured with 1280x720.  That's step 1.

The sink crop operates within that rectangle, cropping it to an area.
Let's say we're only interested in its centre, so we'd chose 640x360
with the top-left as 320,180.  This is step 2.

Then, if we want to down-scale by a factor of two, we'd set the sink
compose selection to 320x180.

This seems to be at odds with how the scaling is done in CSI at
present: the selection implementations all reject attempts to
configure the sink pad, instead only supporting crop rectangles on
the source, and we use the source crop rectangle to define the
down-scaling.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: Still OOM problems with 4.9er/4.10er kernels

2017-03-19 Thread Michal Hocko
On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:
> On 17.03.2017 18:13, Michal Hocko wrote:
> >On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
> >[...]
> >>Why does the kernel prefer to swapin/out and not use
> >>
> >>a.) the free memory?
> >It will use all the free memory up to min watermark which is set up
> >based on min_free_kbytes.
> 
> Makes sense, how is /proc/sys/vm/min_free_kbytes default value calculated?

See init_per_zone_wmark_min

> >>b.) the buffer/cache?
> >the memory reclaim is strongly biased towards page cache and we try to
> >avoid swapout as much as possible (see get_scan_count).
> 
> If I understand it correctly, swapping is preferred over dropping the
> cache, right. Can this behaviour be changed to prefer dropping the
> cache to some minimum amount?  Is this also configurable in a way?

No, we enforce swapping if the amount of free + file pages are below the
cumulative high watermark.

> (As far as I remember e.g. kernel 2.4 dropped the caches well).
> 
> >>There is ~100M memory available but kernel swaps all the time ...
> >>
> >>Any ideas?
> >>
> >>Kernel: 4.9.14-200.fc25.x86_64
> >>
> >>top - 17:33:43 up 28 min,  3 users,  load average: 3.58, 1.67, 0.89
> >>Tasks: 145 total,   4 running, 141 sleeping,   0 stopped,   0 zombie
> >>%Cpu(s): 19.1 us, 56.2 sy,  0.0 ni,  4.3 id, 13.4 wa, 2.0 hi,  0.3 si,  4.7
> >>st
> >>KiB Mem :   230076 total,61508 free,   123472 used,45096 buff/cache
> >>
> >>procs ---memory-- ---swap-- -io -system--
> >>--cpu-
> >>  r  b   swpd   free   buff  cache   si   sobibo in   cs us sy id 
> >> wa st
> >>  3  5 303916  60372328  43864 27828  200 41420   236 6984 11138 11 47  
> >> 6 23 14
> >I am really surprised to see any reclaim at all. 26% of free memory
> >doesn't sound as if we should do a reclaim at all. Do you have an
> >unusual configuration of /proc/sys/vm/min_free_kbytes ? Or is there
> >anything running inside a memory cgroup with a small limit?
> 
> nothing special set regarding /proc/sys/vm/min_free_kbytes (default values),
> detailed config below. Regarding cgroups, none of I know. How to check (I
> guess nothing is set because cg* commands are not available)?

be careful because systemd started to use some controllers. You can
easily check cgroup mount points.

> /proc/sys/vm/min_free_kbytes
> 45056

So at least 45M will be kept reserved for the system. Your data
indicated you had more memory. How does /proc/zoneinfo look like?
Btw. you seem to be using fc kernel, are there any patches applied on
top of Linus tree? Could you try to retest vanilla kernel?
-- 
Michal Hocko
SUSE Labs


Re: Still OOM problems with 4.9er/4.10er kernels

2017-03-19 Thread Michal Hocko
On Fri 17-03-17 21:08:31, Gerhard Wiesinger wrote:
> On 17.03.2017 18:13, Michal Hocko wrote:
> >On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote:
> >[...]
> >>Why does the kernel prefer to swapin/out and not use
> >>
> >>a.) the free memory?
> >It will use all the free memory up to min watermark which is set up
> >based on min_free_kbytes.
> 
> Makes sense, how is /proc/sys/vm/min_free_kbytes default value calculated?

See init_per_zone_wmark_min

> >>b.) the buffer/cache?
> >the memory reclaim is strongly biased towards page cache and we try to
> >avoid swapout as much as possible (see get_scan_count).
> 
> If I understand it correctly, swapping is preferred over dropping the
> cache, right. Can this behaviour be changed to prefer dropping the
> cache to some minimum amount?  Is this also configurable in a way?

No, we enforce swapping if the amount of free + file pages are below the
cumulative high watermark.

> (As far as I remember e.g. kernel 2.4 dropped the caches well).
> 
> >>There is ~100M memory available but kernel swaps all the time ...
> >>
> >>Any ideas?
> >>
> >>Kernel: 4.9.14-200.fc25.x86_64
> >>
> >>top - 17:33:43 up 28 min,  3 users,  load average: 3.58, 1.67, 0.89
> >>Tasks: 145 total,   4 running, 141 sleeping,   0 stopped,   0 zombie
> >>%Cpu(s): 19.1 us, 56.2 sy,  0.0 ni,  4.3 id, 13.4 wa, 2.0 hi,  0.3 si,  4.7
> >>st
> >>KiB Mem :   230076 total,61508 free,   123472 used,45096 buff/cache
> >>
> >>procs ---memory-- ---swap-- -io -system--
> >>--cpu-
> >>  r  b   swpd   free   buff  cache   si   sobibo in   cs us sy id 
> >> wa st
> >>  3  5 303916  60372328  43864 27828  200 41420   236 6984 11138 11 47  
> >> 6 23 14
> >I am really surprised to see any reclaim at all. 26% of free memory
> >doesn't sound as if we should do a reclaim at all. Do you have an
> >unusual configuration of /proc/sys/vm/min_free_kbytes ? Or is there
> >anything running inside a memory cgroup with a small limit?
> 
> nothing special set regarding /proc/sys/vm/min_free_kbytes (default values),
> detailed config below. Regarding cgroups, none of I know. How to check (I
> guess nothing is set because cg* commands are not available)?

be careful because systemd started to use some controllers. You can
easily check cgroup mount points.

> /proc/sys/vm/min_free_kbytes
> 45056

So at least 45M will be kept reserved for the system. Your data
indicated you had more memory. How does /proc/zoneinfo look like?
Btw. you seem to be using fc kernel, are there any patches applied on
top of Linus tree? Could you try to retest vanilla kernel?
-- 
Michal Hocko
SUSE Labs


Re: [PATCH v6 0/4] i.MX7 PCI support

2017-03-19 Thread Dong Aisheng
On Tue, Mar 14, 2017 at 08:18:23AM -0700, Andrey Smirnov wrote:
> Hello, everyone:
> 
> This is a sixth iteration of the code that adds PCI-subsystem bits
> necessary for enabling PCI support on i.MX7.
> 



> Andrey Smirnov (4):
>   PCI: imx6: Add code to support i.MX7D
>   PCI: imx6: Do not wait for speed change on i.MX7
>   PCI: imx6: Do not switch speed if Gen2 is disabled
>   PCI: imx6: Allow probe deferal by reset GPIO
> 
>  .../devicetree/bindings/pci/fsl,imx6q-pcie.txt |  13 +-
>  drivers/pci/host/pci-imx6.c| 199 
> +++--

Can't apply and test it.

The directory has been changed to drivers/pci/host/dwc/pci-imx6.c
since the commit below:
commit 950bf6388bc22c2749b8b66c501df1462639d6bd
Author: Kishon Vijay Abraham I 
Date:   Fri Jan 6 18:22:48 2017 +0530

PCI: Move DesignWare IP support to new drivers/pci/dwc/ directory

Group all the PCI drivers that use DesignWare core in dwc directory.
dwc IP is capable of operating in both host mode and device mode and
keeping it inside the *host* directory is misleading.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jingoo Han 
Acked-By: Joao Pinto 

Regards
Dong Aisheng

>  include/linux/mfd/syscon/imx7-iomuxc-gpr.h |   4 +
>  3 files changed, 161 insertions(+), 55 deletions(-)
> 


> -- 
> 2.9.3
> 


Re: [PATCH v6 0/4] i.MX7 PCI support

2017-03-19 Thread Dong Aisheng
On Tue, Mar 14, 2017 at 08:18:23AM -0700, Andrey Smirnov wrote:
> Hello, everyone:
> 
> This is a sixth iteration of the code that adds PCI-subsystem bits
> necessary for enabling PCI support on i.MX7.
> 



> Andrey Smirnov (4):
>   PCI: imx6: Add code to support i.MX7D
>   PCI: imx6: Do not wait for speed change on i.MX7
>   PCI: imx6: Do not switch speed if Gen2 is disabled
>   PCI: imx6: Allow probe deferal by reset GPIO
> 
>  .../devicetree/bindings/pci/fsl,imx6q-pcie.txt |  13 +-
>  drivers/pci/host/pci-imx6.c| 199 
> +++--

Can't apply and test it.

The directory has been changed to drivers/pci/host/dwc/pci-imx6.c
since the commit below:
commit 950bf6388bc22c2749b8b66c501df1462639d6bd
Author: Kishon Vijay Abraham I 
Date:   Fri Jan 6 18:22:48 2017 +0530

PCI: Move DesignWare IP support to new drivers/pci/dwc/ directory

Group all the PCI drivers that use DesignWare core in dwc directory.
dwc IP is capable of operating in both host mode and device mode and
keeping it inside the *host* directory is misleading.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jingoo Han 
Acked-By: Joao Pinto 

Regards
Dong Aisheng

>  include/linux/mfd/syscon/imx7-iomuxc-gpr.h |   4 +
>  3 files changed, 161 insertions(+), 55 deletions(-)
> 


> -- 
> 2.9.3
> 


Re: [PATCH v5 00/39] i.MX Media Driver

2017-03-19 Thread Russell King - ARM Linux
On Sun, Mar 19, 2017 at 05:00:08PM +0200, Vladimir Zapolskiy wrote:
> On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote:
> > On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote:
> >> There's a good reason why I dumped a full debug log using GST_DEBUG=*:9,
> >> analysed it for the cause of the failure, and tried several different
> >> pipelines, including the standard bayer2rgb plugin.
> >>
> >> Please don't blame this on random stuff after analysis of the logs _and_
> >> reading the appropriate plugin code has shown where the problem is.  I
> >> know gstreamer can be very complex, but it's very possible to analyse
> >> the cause of problems and pin them down with detailed logs in conjunction
> >> with the source code.
> > 
> > Oh, and the proof of correct analysis is that fixing the kernel capture
> > driver to enumerate the frame sizes and intervals fixes the issue, even
> > with bayer2rgbneon being used.
> > 
> > Therefore, there is _no way_ what so ever that it could be caused by that
> > plugin.
> > 
> 
> Hey, no blaming of the unknown to me bayer2rgbneon element from my side,
> I've just asked an innocent question, thanks for reply. I failed to find
> the source code of the plugin, I was interested to compare its performance
> and features with mine in-house NEON powered RGGB/BGGR to RGB24 GStreamer
> conversion element, which is written years ago. My question was offtopic.

If you wanted to know where to get it from, you should've asked that.
You can find all the bits here:

https://git.phytec.de/

You need bayer2rgb-neon and gst-bayer2rgb-neon, and it requires some
fixes to the configure script and Makefiles get it to build if you
don't have gengenopt available.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH v5 00/39] i.MX Media Driver

2017-03-19 Thread Russell King - ARM Linux
On Sun, Mar 19, 2017 at 05:00:08PM +0200, Vladimir Zapolskiy wrote:
> On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote:
> > On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote:
> >> There's a good reason why I dumped a full debug log using GST_DEBUG=*:9,
> >> analysed it for the cause of the failure, and tried several different
> >> pipelines, including the standard bayer2rgb plugin.
> >>
> >> Please don't blame this on random stuff after analysis of the logs _and_
> >> reading the appropriate plugin code has shown where the problem is.  I
> >> know gstreamer can be very complex, but it's very possible to analyse
> >> the cause of problems and pin them down with detailed logs in conjunction
> >> with the source code.
> > 
> > Oh, and the proof of correct analysis is that fixing the kernel capture
> > driver to enumerate the frame sizes and intervals fixes the issue, even
> > with bayer2rgbneon being used.
> > 
> > Therefore, there is _no way_ what so ever that it could be caused by that
> > plugin.
> > 
> 
> Hey, no blaming of the unknown to me bayer2rgbneon element from my side,
> I've just asked an innocent question, thanks for reply. I failed to find
> the source code of the plugin, I was interested to compare its performance
> and features with mine in-house NEON powered RGGB/BGGR to RGB24 GStreamer
> conversion element, which is written years ago. My question was offtopic.

If you wanted to know where to get it from, you should've asked that.
You can find all the bits here:

https://git.phytec.de/

You need bayer2rgb-neon and gst-bayer2rgb-neon, and it requires some
fixes to the configure script and Makefiles get it to build if you
don't have gengenopt available.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH] mm: use BITS_PER_LONG to unify the definition in page->flags

2017-03-19 Thread Michal Hocko
On Sun 19-03-17 23:03:45, Wei Yang wrote:
> On Sun, Mar 19, 2017 at 10:30:13AM -0400, Michal Hocko wrote:
> >On Sat 18-03-17 08:39:14, Wei Yang wrote:
> >> The field page->flags is defined as unsigned long and is divided into
> >> several parts to store different information of the page, like section,
> >> node, zone. Which means all parts must sit in the one "unsigned
> >> long".
> >> 
> >> BITS_PER_LONG is used in several places to ensure this applies.
> >> 
> >> #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - 
> >> NR_PAGEFLAGS
> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT <= BITS_PER_LONG - 
> >> NR_PAGEFLAGS
> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= 
> >> BITS_PER_LONG - NR_PAGEFLAGS
> >> 
> >> While we use "sizeof(unsigned long) * 8" in the definition of
> >> SECTIONS_PGOFF
> >> 
> >> #define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - 
> >> SECTIONS_WIDTH)
> >> 
> >> This may not be that obvious for audience to catch the point.
> >> 
> >> This patch replaces the "sizeof(unsigned long) * 8" with BITS_PER_LONG to
> >> make all this consistent.
> >
> >I am not really sure this is an improvement. page::flags is unsigned
> >long nad the current code reflects that type.
> >
> 
> Hi, Michal
> 
> Glad to hear from you.
> 
> I think the purpose of definition BITS_PER_LONG is more easily to let audience
> know it is the number of bits of type long. If it has no improvement, we don't
> need to define a specific macro .
> 
> And as you could see, several related macros use BITS_PER_LONG in their
> definition. After this change, all of them will have a consistent definition.
> 
> After this change, code looks more neat :-)
> 
> So it looks more reasonable to use this.

I do not think that this is sufficient to justify the change.

-- 
Michal Hocko
SUSE Labs


Re: [PATCH v6 2/2] soc/imx: Add GPCv2 power gating driver

2017-03-19 Thread Dong Aisheng
On Thu, Mar 16, 2017 at 06:30:50AM -0700, Andrey Smirnov wrote:
> Add code allowing for control of various power domains managed by GPCv2
> IP block found in i.MX7 series of SoCs. Power domains covered by this
> patch are:
> 
> - PCIE PHY
> - MIPI PHY
> - USB HSIC PHY
> - USB OTG1/2 PHY
> 
> Support for any other power domain controlled by GPC is not present, and
> can be added at some later point.
> 
> Testing of this code was done against a PCIe driver.
> 
> Cc: yurov...@gmail.com
> Cc: Lucas Stach 
> Cc: Fabio Estevam 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/imx/Kconfig  |  10 ++
>  drivers/soc/imx/Makefile |   1 +
>  drivers/soc/imx/gpcv2.c  | 385 
> +++

Personally i'd like more naming gpc-imx7.c since gpcv2 is too generic,
and actually you also mix using imx7d name below.

And AFAIK only MX7 will use this new driver.

Probably should also change the exist gpc to gpc-imx6.

>  4 files changed, 397 insertions(+)
>  create mode 100644 drivers/soc/imx/Kconfig
>  create mode 100644 drivers/soc/imx/gpcv2.c
> 
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f31bceb..55a4eb8 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>  
>  source "drivers/soc/bcm/Kconfig"
>  source "drivers/soc/fsl/Kconfig"
> +source "drivers/soc/imx/Kconfig"
>  source "drivers/soc/mediatek/Kconfig"
>  source "drivers/soc/qcom/Kconfig"
>  source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
> new file mode 100644
> index 000..bc7f0ee0
> --- /dev/null
> +++ b/drivers/soc/imx/Kconfig
> @@ -0,0 +1,10 @@
> +menu "i.MX SoC drivers"
> +
> +config IMX7_PM_DOMAINS
> + bool "i.MX7 PM domains"
> + select PM_GENERIC_DOMAINS
> + depends on SOC_IMX7D || (COMPILE_TEST && OF)
> + default y if SOC_IMX7D
> +
> +endmenu
> +
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> index 35861f5..5b6e396 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -1 +1,2 @@
>  obj-y += gpc.o
> +obj-$(CONFIG_IMX7_PM_DOMAINS) += gpcv2.o
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> new file mode 100644
> index 000..73c58ca
> --- /dev/null
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -0,0 +1,385 @@
> +/*
> + * Copyright 2017 Impinj, Inc
> + * Author: Andrey Smirnov 
> + *
> + * Based on the code of analogus driver:
> + *
> + * Copyright 2015-2017 Pengutronix, Lucas Stach 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include 

Where did you use it?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GPC_PGC_CPU_MAPPING  0xec
> +#define USB_HSIC_PHY_A7_DOMAIN   BIT(6)
> +#define USB_OTG2_PHY_A7_DOMAIN   BIT(5)
> +#define USB_OTG1_PHY_A7_DOMAIN   BIT(4)
> +#define PCIE_PHY_A7_DOMAIN   BIT(3)
> +#define MIPI_PHY_A7_DOMAIN   BIT(2)
> +
> +#define GPC_PU_PGC_SW_PUP_REQ0xf8
> +#define GPC_PU_PGC_SW_PDN_REQ0x104
> +#define USB_HSIC_PHY_SW_Pxx_REQ  BIT(4)
> +#define USB_OTG2_PHY_SW_Pxx_REQ  BIT(3)
> +#define USB_OTG1_PHY_SW_Pxx_REQ  BIT(2)
> +#define PCIE_PHY_SW_Pxx_REQ  BIT(1)
> +#define MIPI_PHY_SW_Pxx_REQ  BIT(0)
> +
> +#define GPC_MAX_REGISTER 0x1000
> +
> +#define GPC_PGC_nCTRL_PCRBIT(0)
> +
> +struct imx7_pgc_domain {
> + struct generic_pm_domain genpd;
> + struct regmap *regmap;
> + struct regulator *regulator;
> +
> + unsigned int pgc_nctrl;
> +
> + const struct {
> + u32 pxx;
> + u32 map;
> + } bits;
> +
> + const int voltage;
> + struct device *dev;
> +};
> +
> +static int imx7_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
> +   bool on)
> +{
> + struct imx7_pgc_domain *domain = container_of(genpd,
> +   struct imx7_pgc_domain,
> +   genpd);
> + unsigned int offset = on ?
> + GPC_PU_PGC_SW_PUP_REQ : GPC_PU_PGC_SW_PDN_REQ;
> + const bool enable_power_control = domain->pgc_nctrl && !on;
> + const bool has_regulator = !IS_ERR(domain->regulator);
> + unsigned long deadline;
> + int ret = 0;
> +
> + regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
> +domain->bits.map, domain->bits.map);
> +
> + if 

Re: [PATCH] mm: use BITS_PER_LONG to unify the definition in page->flags

2017-03-19 Thread Michal Hocko
On Sun 19-03-17 23:03:45, Wei Yang wrote:
> On Sun, Mar 19, 2017 at 10:30:13AM -0400, Michal Hocko wrote:
> >On Sat 18-03-17 08:39:14, Wei Yang wrote:
> >> The field page->flags is defined as unsigned long and is divided into
> >> several parts to store different information of the page, like section,
> >> node, zone. Which means all parts must sit in the one "unsigned
> >> long".
> >> 
> >> BITS_PER_LONG is used in several places to ensure this applies.
> >> 
> >> #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - 
> >> NR_PAGEFLAGS
> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT <= BITS_PER_LONG - 
> >> NR_PAGEFLAGS
> >> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= 
> >> BITS_PER_LONG - NR_PAGEFLAGS
> >> 
> >> While we use "sizeof(unsigned long) * 8" in the definition of
> >> SECTIONS_PGOFF
> >> 
> >> #define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - 
> >> SECTIONS_WIDTH)
> >> 
> >> This may not be that obvious for audience to catch the point.
> >> 
> >> This patch replaces the "sizeof(unsigned long) * 8" with BITS_PER_LONG to
> >> make all this consistent.
> >
> >I am not really sure this is an improvement. page::flags is unsigned
> >long nad the current code reflects that type.
> >
> 
> Hi, Michal
> 
> Glad to hear from you.
> 
> I think the purpose of definition BITS_PER_LONG is more easily to let audience
> know it is the number of bits of type long. If it has no improvement, we don't
> need to define a specific macro .
> 
> And as you could see, several related macros use BITS_PER_LONG in their
> definition. After this change, all of them will have a consistent definition.
> 
> After this change, code looks more neat :-)
> 
> So it looks more reasonable to use this.

I do not think that this is sufficient to justify the change.

-- 
Michal Hocko
SUSE Labs


Re: [PATCH v6 2/2] soc/imx: Add GPCv2 power gating driver

2017-03-19 Thread Dong Aisheng
On Thu, Mar 16, 2017 at 06:30:50AM -0700, Andrey Smirnov wrote:
> Add code allowing for control of various power domains managed by GPCv2
> IP block found in i.MX7 series of SoCs. Power domains covered by this
> patch are:
> 
> - PCIE PHY
> - MIPI PHY
> - USB HSIC PHY
> - USB OTG1/2 PHY
> 
> Support for any other power domain controlled by GPC is not present, and
> can be added at some later point.
> 
> Testing of this code was done against a PCIe driver.
> 
> Cc: yurov...@gmail.com
> Cc: Lucas Stach 
> Cc: Fabio Estevam 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/imx/Kconfig  |  10 ++
>  drivers/soc/imx/Makefile |   1 +
>  drivers/soc/imx/gpcv2.c  | 385 
> +++

Personally i'd like more naming gpc-imx7.c since gpcv2 is too generic,
and actually you also mix using imx7d name below.

And AFAIK only MX7 will use this new driver.

Probably should also change the exist gpc to gpc-imx6.

>  4 files changed, 397 insertions(+)
>  create mode 100644 drivers/soc/imx/Kconfig
>  create mode 100644 drivers/soc/imx/gpcv2.c
> 
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f31bceb..55a4eb8 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>  
>  source "drivers/soc/bcm/Kconfig"
>  source "drivers/soc/fsl/Kconfig"
> +source "drivers/soc/imx/Kconfig"
>  source "drivers/soc/mediatek/Kconfig"
>  source "drivers/soc/qcom/Kconfig"
>  source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
> new file mode 100644
> index 000..bc7f0ee0
> --- /dev/null
> +++ b/drivers/soc/imx/Kconfig
> @@ -0,0 +1,10 @@
> +menu "i.MX SoC drivers"
> +
> +config IMX7_PM_DOMAINS
> + bool "i.MX7 PM domains"
> + select PM_GENERIC_DOMAINS
> + depends on SOC_IMX7D || (COMPILE_TEST && OF)
> + default y if SOC_IMX7D
> +
> +endmenu
> +
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> index 35861f5..5b6e396 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -1 +1,2 @@
>  obj-y += gpc.o
> +obj-$(CONFIG_IMX7_PM_DOMAINS) += gpcv2.o
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> new file mode 100644
> index 000..73c58ca
> --- /dev/null
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -0,0 +1,385 @@
> +/*
> + * Copyright 2017 Impinj, Inc
> + * Author: Andrey Smirnov 
> + *
> + * Based on the code of analogus driver:
> + *
> + * Copyright 2015-2017 Pengutronix, Lucas Stach 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include 

Where did you use it?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GPC_PGC_CPU_MAPPING  0xec
> +#define USB_HSIC_PHY_A7_DOMAIN   BIT(6)
> +#define USB_OTG2_PHY_A7_DOMAIN   BIT(5)
> +#define USB_OTG1_PHY_A7_DOMAIN   BIT(4)
> +#define PCIE_PHY_A7_DOMAIN   BIT(3)
> +#define MIPI_PHY_A7_DOMAIN   BIT(2)
> +
> +#define GPC_PU_PGC_SW_PUP_REQ0xf8
> +#define GPC_PU_PGC_SW_PDN_REQ0x104
> +#define USB_HSIC_PHY_SW_Pxx_REQ  BIT(4)
> +#define USB_OTG2_PHY_SW_Pxx_REQ  BIT(3)
> +#define USB_OTG1_PHY_SW_Pxx_REQ  BIT(2)
> +#define PCIE_PHY_SW_Pxx_REQ  BIT(1)
> +#define MIPI_PHY_SW_Pxx_REQ  BIT(0)
> +
> +#define GPC_MAX_REGISTER 0x1000
> +
> +#define GPC_PGC_nCTRL_PCRBIT(0)
> +
> +struct imx7_pgc_domain {
> + struct generic_pm_domain genpd;
> + struct regmap *regmap;
> + struct regulator *regulator;
> +
> + unsigned int pgc_nctrl;
> +
> + const struct {
> + u32 pxx;
> + u32 map;
> + } bits;
> +
> + const int voltage;
> + struct device *dev;
> +};
> +
> +static int imx7_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
> +   bool on)
> +{
> + struct imx7_pgc_domain *domain = container_of(genpd,
> +   struct imx7_pgc_domain,
> +   genpd);
> + unsigned int offset = on ?
> + GPC_PU_PGC_SW_PUP_REQ : GPC_PU_PGC_SW_PDN_REQ;
> + const bool enable_power_control = domain->pgc_nctrl && !on;
> + const bool has_regulator = !IS_ERR(domain->regulator);
> + unsigned long deadline;
> + int ret = 0;
> +
> + regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
> +domain->bits.map, domain->bits.map);
> +
> + if (has_regulator && on) {
> + ret = regulator_enable(domain->regulator);
> + if (ret) {
> +  

Re: [PATCH] mm: use BITS_PER_LONG to unify the definition in page->flags

2017-03-19 Thread Wei Yang
On Sun, Mar 19, 2017 at 10:30:13AM -0400, Michal Hocko wrote:
>On Sat 18-03-17 08:39:14, Wei Yang wrote:
>> The field page->flags is defined as unsigned long and is divided into
>> several parts to store different information of the page, like section,
>> node, zone. Which means all parts must sit in the one "unsigned
>> long".
>> 
>> BITS_PER_LONG is used in several places to ensure this applies.
>> 
>> #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
>> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT <= BITS_PER_LONG - 
>> NR_PAGEFLAGS
>> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= 
>> BITS_PER_LONG - NR_PAGEFLAGS
>> 
>> While we use "sizeof(unsigned long) * 8" in the definition of
>> SECTIONS_PGOFF
>> 
>> #define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - 
>> SECTIONS_WIDTH)
>> 
>> This may not be that obvious for audience to catch the point.
>> 
>> This patch replaces the "sizeof(unsigned long) * 8" with BITS_PER_LONG to
>> make all this consistent.
>
>I am not really sure this is an improvement. page::flags is unsigned
>long nad the current code reflects that type.
>

Hi, Michal

Glad to hear from you.

I think the purpose of definition BITS_PER_LONG is more easily to let audience
know it is the number of bits of type long. If it has no improvement, we don't
need to define a specific macro .

And as you could see, several related macros use BITS_PER_LONG in their
definition. After this change, all of them will have a consistent definition.

After this change, code looks more neat :-)

So it looks more reasonable to use this.

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH] mm: use BITS_PER_LONG to unify the definition in page->flags

2017-03-19 Thread Wei Yang
On Sun, Mar 19, 2017 at 10:30:13AM -0400, Michal Hocko wrote:
>On Sat 18-03-17 08:39:14, Wei Yang wrote:
>> The field page->flags is defined as unsigned long and is divided into
>> several parts to store different information of the page, like section,
>> node, zone. Which means all parts must sit in the one "unsigned
>> long".
>> 
>> BITS_PER_LONG is used in several places to ensure this applies.
>> 
>> #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
>> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT <= BITS_PER_LONG - 
>> NR_PAGEFLAGS
>> #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= 
>> BITS_PER_LONG - NR_PAGEFLAGS
>> 
>> While we use "sizeof(unsigned long) * 8" in the definition of
>> SECTIONS_PGOFF
>> 
>> #define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - 
>> SECTIONS_WIDTH)
>> 
>> This may not be that obvious for audience to catch the point.
>> 
>> This patch replaces the "sizeof(unsigned long) * 8" with BITS_PER_LONG to
>> make all this consistent.
>
>I am not really sure this is an improvement. page::flags is unsigned
>long nad the current code reflects that type.
>

Hi, Michal

Glad to hear from you.

I think the purpose of definition BITS_PER_LONG is more easily to let audience
know it is the number of bits of type long. If it has no improvement, we don't
need to define a specific macro .

And as you could see, several related macros use BITS_PER_LONG in their
definition. After this change, all of them will have a consistent definition.

After this change, code looks more neat :-)

So it looks more reasonable to use this.

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature


Re: [PATCH v5 00/39] i.MX Media Driver

2017-03-19 Thread Vladimir Zapolskiy
On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote:
> On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote:
>> There's a good reason why I dumped a full debug log using GST_DEBUG=*:9,
>> analysed it for the cause of the failure, and tried several different
>> pipelines, including the standard bayer2rgb plugin.
>>
>> Please don't blame this on random stuff after analysis of the logs _and_
>> reading the appropriate plugin code has shown where the problem is.  I
>> know gstreamer can be very complex, but it's very possible to analyse
>> the cause of problems and pin them down with detailed logs in conjunction
>> with the source code.
> 
> Oh, and the proof of correct analysis is that fixing the kernel capture
> driver to enumerate the frame sizes and intervals fixes the issue, even
> with bayer2rgbneon being used.
> 
> Therefore, there is _no way_ what so ever that it could be caused by that
> plugin.
> 

Hey, no blaming of the unknown to me bayer2rgbneon element from my side,
I've just asked an innocent question, thanks for reply. I failed to find
the source code of the plugin, I was interested to compare its performance
and features with mine in-house NEON powered RGGB/BGGR to RGB24 GStreamer
conversion element, which is written years ago. My question was offtopic.

--
With best wishes,
Vladimir


Re: [PATCH v5 00/39] i.MX Media Driver

2017-03-19 Thread Vladimir Zapolskiy
On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote:
> On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote:
>> There's a good reason why I dumped a full debug log using GST_DEBUG=*:9,
>> analysed it for the cause of the failure, and tried several different
>> pipelines, including the standard bayer2rgb plugin.
>>
>> Please don't blame this on random stuff after analysis of the logs _and_
>> reading the appropriate plugin code has shown where the problem is.  I
>> know gstreamer can be very complex, but it's very possible to analyse
>> the cause of problems and pin them down with detailed logs in conjunction
>> with the source code.
> 
> Oh, and the proof of correct analysis is that fixing the kernel capture
> driver to enumerate the frame sizes and intervals fixes the issue, even
> with bayer2rgbneon being used.
> 
> Therefore, there is _no way_ what so ever that it could be caused by that
> plugin.
> 

Hey, no blaming of the unknown to me bayer2rgbneon element from my side,
I've just asked an innocent question, thanks for reply. I failed to find
the source code of the plugin, I was interested to compare its performance
and features with mine in-house NEON powered RGGB/BGGR to RGB24 GStreamer
conversion element, which is written years ago. My question was offtopic.

--
With best wishes,
Vladimir


Re: [PATCH v5 00/39] i.MX Media Driver

2017-03-19 Thread Nicolas Dufresne
Le dimanche 19 mars 2017 à 00:54 +, Russell King - ARM Linux a
écrit :
> > 
> > In practice, I have the impression there is a fair reason why
> > framerate
> > enumeration isn't implemented (considering there is only 1 valid
> > rate).
> 
> That's actually completely incorrect.
> 
> With the capture device interfacing directly with CSI, it's possible
> _today_ to select:
> 
> * the CSI sink pad's resolution
> * the CSI sink pad's resolution with the width and/or height halved
> * the CSI sink pad's frame rate
> * the CSI sink pad's frame rate divided by the frame drop factor
> 
> To put it another way, these are possible:
> 
> # v4l2-ctl -d /dev/video10 --list-formats-ext
> ioctl: VIDIOC_ENUM_FMT
>     Index   : 0
>     Type    : Video Capture
>     Pixel Format: 'RGGB'
>     Name    : 8-bit Bayer RGRG/GBGB
>     Size: Discrete 816x616
>     Interval: Discrete 0.040s (25.000 fps)
>     Interval: Discrete 0.048s (20.833 fps)
>     Interval: Discrete 0.050s (20.000 fps)
>     Interval: Discrete 0.053s (18.750 fps)
>     Interval: Discrete 0.060s (16.667 fps)
>     Interval: Discrete 0.067s (15.000 fps)
>     Interval: Discrete 0.080s (12.500 fps)
>     Interval: Discrete 0.100s (10.000 fps)
>     Interval: Discrete 0.120s (8.333 fps)
>     Interval: Discrete 0.160s (6.250 fps)
>     Interval: Discrete 0.200s (5.000 fps)
>     Interval: Discrete 0.240s (4.167 fps)
>     Size: Discrete 408x616
> 
>     Size: Discrete 816x308
> 
>     Size: Discrete 408x308
> 
> 
> These don't become possible as a result of implementing the enums,
> they're all already requestable through /dev/video10.

Ok that wasn't clear. So basically video9 is a front-end to video10,
and it does not proxy the enumerations. I understand this is what you
are now fixing. And this has to be fixed, because I can image cases
where the front-end could support only a subset of the sub-dev. So
having userspace enumerate on another device (and having to find this
device by walking the tree) is unlikely to work in all scenarios.

regards,
Nicolas

p.s. This is why caps negotiation is annoyingly complex in GStreamer,
specially that there is no shortcut, you connect pads, and they figure-
out what format they will use between each other.

signature.asc
Description: This is a digitally signed message part


Re: [PATCH v5 00/39] i.MX Media Driver

2017-03-19 Thread Nicolas Dufresne
Le dimanche 19 mars 2017 à 00:54 +, Russell King - ARM Linux a
écrit :
> > 
> > In practice, I have the impression there is a fair reason why
> > framerate
> > enumeration isn't implemented (considering there is only 1 valid
> > rate).
> 
> That's actually completely incorrect.
> 
> With the capture device interfacing directly with CSI, it's possible
> _today_ to select:
> 
> * the CSI sink pad's resolution
> * the CSI sink pad's resolution with the width and/or height halved
> * the CSI sink pad's frame rate
> * the CSI sink pad's frame rate divided by the frame drop factor
> 
> To put it another way, these are possible:
> 
> # v4l2-ctl -d /dev/video10 --list-formats-ext
> ioctl: VIDIOC_ENUM_FMT
>     Index   : 0
>     Type    : Video Capture
>     Pixel Format: 'RGGB'
>     Name    : 8-bit Bayer RGRG/GBGB
>     Size: Discrete 816x616
>     Interval: Discrete 0.040s (25.000 fps)
>     Interval: Discrete 0.048s (20.833 fps)
>     Interval: Discrete 0.050s (20.000 fps)
>     Interval: Discrete 0.053s (18.750 fps)
>     Interval: Discrete 0.060s (16.667 fps)
>     Interval: Discrete 0.067s (15.000 fps)
>     Interval: Discrete 0.080s (12.500 fps)
>     Interval: Discrete 0.100s (10.000 fps)
>     Interval: Discrete 0.120s (8.333 fps)
>     Interval: Discrete 0.160s (6.250 fps)
>     Interval: Discrete 0.200s (5.000 fps)
>     Interval: Discrete 0.240s (4.167 fps)
>     Size: Discrete 408x616
> 
>     Size: Discrete 816x308
> 
>     Size: Discrete 408x308
> 
> 
> These don't become possible as a result of implementing the enums,
> they're all already requestable through /dev/video10.

Ok that wasn't clear. So basically video9 is a front-end to video10,
and it does not proxy the enumerations. I understand this is what you
are now fixing. And this has to be fixed, because I can image cases
where the front-end could support only a subset of the sub-dev. So
having userspace enumerate on another device (and having to find this
device by walking the tree) is unlikely to work in all scenarios.

regards,
Nicolas

p.s. This is why caps negotiation is annoyingly complex in GStreamer,
specially that there is no shortcut, you connect pads, and they figure-
out what format they will use between each other.

signature.asc
Description: This is a digitally signed message part


[PATCH v2 1/2] staging: speakup: Moved OR operator to previous line.

2017-03-19 Thread Arushi Singhal
Moved logical OR operator to previous line to fix the following
checkpatch issue:

CHECK: Logical continuations should be on the previous line.

Signed-off-by: Arushi Singhal 
---
changes in v2
  -change the commit message and subject.

 drivers/staging/speakup/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index c10445624e92..def1a36da9dd 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2173,10 +2173,10 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (up_flag || spk_killed || type == KT_SHIFT)
goto out;
spk_shut_up &= 0xfe;
-   kh = (value == KVAL(K_DOWN))
-   || (value == KVAL(K_UP))
-   || (value == KVAL(K_LEFT))
-   || (value == KVAL(K_RIGHT));
+   kh = (value == KVAL(K_DOWN)) ||
+   (value == KVAL(K_UP)) ||
+   (value == KVAL(K_LEFT)) ||
+   (value == KVAL(K_RIGHT));
if ((cursor_track != read_all_mode) || !kh)
if (!spk_no_intr)
spk_do_flush();
-- 
2.11.0



[PATCH v2 1/2] staging: speakup: Moved OR operator to previous line.

2017-03-19 Thread Arushi Singhal
Moved logical OR operator to previous line to fix the following
checkpatch issue:

CHECK: Logical continuations should be on the previous line.

Signed-off-by: Arushi Singhal 
---
changes in v2
  -change the commit message and subject.

 drivers/staging/speakup/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index c10445624e92..def1a36da9dd 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2173,10 +2173,10 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (up_flag || spk_killed || type == KT_SHIFT)
goto out;
spk_shut_up &= 0xfe;
-   kh = (value == KVAL(K_DOWN))
-   || (value == KVAL(K_UP))
-   || (value == KVAL(K_LEFT))
-   || (value == KVAL(K_RIGHT));
+   kh = (value == KVAL(K_DOWN)) ||
+   (value == KVAL(K_UP)) ||
+   (value == KVAL(K_LEFT)) ||
+   (value == KVAL(K_RIGHT));
if ((cursor_track != read_all_mode) || !kh)
if (!spk_no_intr)
spk_do_flush();
-- 
2.11.0



<    1   2   3   4   5   6   >