[PATCH 0/4] staging:rtl8192u: Style changes r819xU_firmware.h
This short series of patches just clears simple checkpatch issues with the header file r819xU_firmware.h. John Whitmore (4): staging:rtl8192u: Remove unused RTL8190_CPU_START_OFFSET - Style staging:rtl8192u: Refactor GET_COMMAND_PACKET_FRAG_THRESHOLD - Style staging:rtl8192u: Remove typedef from firmware_init_step_e - Style staging:rtl8192u: Remove typedef from enum opt_rst_type_e - Style drivers/staging/rtl8192u/r819xU_firmware.c | 4 ++-- drivers/staging/rtl8192u/r819xU_firmware.h | 11 +-- 2 files changed, 7 insertions(+), 8 deletions(-) -- 2.18.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging:rtl8192u: Remove typedef from enum opt_rst_type_e - Style
Remove the typedef directive from enumerated type opt_rst_type_e,
this change clears the checkpatch issue with defining new types in
the code.
This is a coding style change which should not impact runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_firmware.c | 2 +-
drivers/staging/rtl8192u/r819xU_firmware.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c
b/drivers/staging/rtl8192u/r819xU_firmware.c
index 15fd026638fe..c3ea906f3af3 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware.c
@@ -208,7 +208,7 @@ bool init_firmware(struct net_device *dev)
u32 file_length = 0;
u8 *mapped_file = NULL;
u32 init_step = 0;
- opt_rst_type_e rst_opt = OPT_SYSTEM_RESET;
+ enum opt_rst_type_erst_opt = OPT_SYSTEM_RESET;
enum firmware_init_step_e starting_state = FW_INIT_STEP0_BOOT;
rt_firmware *pfirmware = priv->pFirmware;
diff --git a/drivers/staging/rtl8192u/r819xU_firmware.h
b/drivers/staging/rtl8192u/r819xU_firmware.h
index 870301853480..b84344c1e62b 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.h
+++ b/drivers/staging/rtl8192u/r819xU_firmware.h
@@ -11,9 +11,9 @@ enum firmware_init_step_e {
FW_INIT_STEP2_DATA = 2,
};
-typedef enum _opt_rst_type {
+enum opt_rst_type_e {
OPT_SYSTEM_RESET = 0,
OPT_FIRMWARE_RESET = 1,
-} opt_rst_type_e;
+};
#endif
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging:rtl8192u: Remove typedef from firmware_init_step_e - Style
Remove the typedef directive from enumerated type firmware_init_step_e
this clears the checkpatch issue with adding new types to the code.
This is a coding style change which should have no impact on runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_firmware.c | 2 +-
drivers/staging/rtl8192u/r819xU_firmware.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c
b/drivers/staging/rtl8192u/r819xU_firmware.c
index 9c7e19aedff1..15fd026638fe 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware.c
@@ -209,7 +209,7 @@ bool init_firmware(struct net_device *dev)
u8 *mapped_file = NULL;
u32 init_step = 0;
opt_rst_type_e rst_opt = OPT_SYSTEM_RESET;
- firmware_init_step_estarting_state = FW_INIT_STEP0_BOOT;
+ enum firmware_init_step_e starting_state = FW_INIT_STEP0_BOOT;
rt_firmware *pfirmware = priv->pFirmware;
const struct firmware *fw_entry;
diff --git a/drivers/staging/rtl8192u/r819xU_firmware.h
b/drivers/staging/rtl8192u/r819xU_firmware.h
index e78e547044b4..870301853480 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.h
+++ b/drivers/staging/rtl8192u/r819xU_firmware.h
@@ -5,11 +5,11 @@
#define GET_COMMAND_PACKET_FRAG_THRESHOLD(v) \
(4 * ((v) / 4) - 8 - USB_HWDESC_HEADER_LEN)
-typedef enum _firmware_init_step {
+enum firmware_init_step_e {
FW_INIT_STEP0_BOOT = 0,
FW_INIT_STEP1_MAIN = 1,
FW_INIT_STEP2_DATA = 2,
-} firmware_init_step_e;
+};
typedef enum _opt_rst_type {
OPT_SYSTEM_RESET = 0,
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging:rtl8192u: Refactor GET_COMMAND_PACKET_FRAG_THRESHOLD - Style
The MACRO GET_COMMAND_PACKET_FRAG_THRESHOLD causes a number of
checkpatch issues so has been refactored to use braces around the
parameter 'v' to avoid precedence issues, and to add spaces around
operators.
These changes are coding style changes which should have no impact
on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/r819xU_firmware.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r819xU_firmware.h
b/drivers/staging/rtl8192u/r819xU_firmware.h
index 794dca7dcd95..e78e547044b4 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.h
+++ b/drivers/staging/rtl8192u/r819xU_firmware.h
@@ -3,7 +3,7 @@
#define __INC_FIRMWARE_H
#define GET_COMMAND_PACKET_FRAG_THRESHOLD(v) \
- (4*(v/4) - 8 - USB_HWDESC_HEADER_LEN)
+ (4 * ((v) / 4) - 8 - USB_HWDESC_HEADER_LEN)
typedef enum _firmware_init_step {
FW_INIT_STEP0_BOOT = 0,
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging:rtl8192u: Remove unused RTL8190_CPU_START_OFFSET - Style
The defined constant RTL8190_CPU_START_OFFSET is not used in the code so has been removed. This is a coding style change which should have no impact on runtime code execution. Signed-off-by: John Whitmore --- drivers/staging/rtl8192u/r819xU_firmware.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r819xU_firmware.h b/drivers/staging/rtl8192u/r819xU_firmware.h index cccd1c82ffe0..794dca7dcd95 100644 --- a/drivers/staging/rtl8192u/r819xU_firmware.h +++ b/drivers/staging/rtl8192u/r819xU_firmware.h @@ -2,7 +2,6 @@ #ifndef __INC_FIRMWARE_H #define __INC_FIRMWARE_H -#define RTL8190_CPU_START_OFFSET 0x80 #define GET_COMMAND_PACKET_FRAG_THRESHOLD(v) \ (4*(v/4) - 8 - USB_HWDESC_HEADER_LEN) -- 2.18.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] Follow-up patches for Cedrus v9
On 09/07/2018 06:33 PM, Paul Kocialkowski wrote: > This brings the requested modifications on top of version 9 of the > Cedrus VPU driver, that implements stateless video decoding using the > Request API. > > Paul Kocialkowski (2): > media: cedrus: Fix error reporting in request validation > media: cedrus: Add TODO file with tasks to complete before unstaging > > drivers/staging/media/sunxi/cedrus/TODO | 7 +++ > drivers/staging/media/sunxi/cedrus/cedrus.c | 15 --- > 2 files changed, 19 insertions(+), 3 deletions(-) > create mode 100644 drivers/staging/media/sunxi/cedrus/TODO > So close... When compiling under e.g. intel I get errors since it doesn't know about the sunxi_sram_claim/release function and the PHYS_PFN_OFFSET define. Is it possible to add stub functions to linux/soc/sunxi/sunxi_sram.h if CONFIG_SUNXI_SRAM is not defined? That would be the best fix for that. The use of PHYS_PFN_OFFSET is weird: are you sure this is the right way? I see that drivers/of/device.c also sets dev->dma_pfn_offset, which makes me wonder if this information shouldn't come from the device tree. You are the only driver that uses this define directly, which makes me suspicious. Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] Follow-up patches for Cedrus v9
On Sat, Sep 8, 2018 at 6:06 PM Hans Verkuil wrote: > > On 09/07/2018 06:33 PM, Paul Kocialkowski wrote: > > This brings the requested modifications on top of version 9 of the > > Cedrus VPU driver, that implements stateless video decoding using the > > Request API. > > > > Paul Kocialkowski (2): > > media: cedrus: Fix error reporting in request validation > > media: cedrus: Add TODO file with tasks to complete before unstaging > > > > drivers/staging/media/sunxi/cedrus/TODO | 7 +++ > > drivers/staging/media/sunxi/cedrus/cedrus.c | 15 --- > > 2 files changed, 19 insertions(+), 3 deletions(-) > > create mode 100644 drivers/staging/media/sunxi/cedrus/TODO > > > > So close... > > When compiling under e.g. intel I get errors since it doesn't know about > the sunxi_sram_claim/release function and the PHYS_PFN_OFFSET define. > > Is it possible to add stub functions to linux/soc/sunxi/sunxi_sram.h > if CONFIG_SUNXI_SRAM is not defined? That would be the best fix for that. > > The use of PHYS_PFN_OFFSET is weird: are you sure this is the right > way? I see that drivers/of/device.c also sets dev->dma_pfn_offset, which > makes me wonder if this information shouldn't come from the device tree. > > You are the only driver that uses this define directly, which makes me > suspicious. On Allwinner platforms, some devices do DMA directly on the memory BUS with the DRAM controller. In such cases, the DRAM has no offset. In all other cases where the DMA goes through the common system bus and the DRAM offset is either 0x4000 or 0x2000, depending on the SoC. Since the former case is not described in the device tree (this is being worked on by Maxime BTW), the dma_pfn_offset is not the value it should be. AFAIK only the display and media subsystems (VPU, camera, TS) are wired this way. In drivers/gpu/drm/sun4i/sun4i_backend.c (the display driver) we use PHYS_OFFSET, which is pretty much the same thing. Regards ChenYu ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] Follow-up patches for Cedrus v9
On 09/08/2018 12:22 PM, Chen-Yu Tsai wrote: > On Sat, Sep 8, 2018 at 6:06 PM Hans Verkuil wrote: >> >> On 09/07/2018 06:33 PM, Paul Kocialkowski wrote: >>> This brings the requested modifications on top of version 9 of the >>> Cedrus VPU driver, that implements stateless video decoding using the >>> Request API. >>> >>> Paul Kocialkowski (2): >>> media: cedrus: Fix error reporting in request validation >>> media: cedrus: Add TODO file with tasks to complete before unstaging >>> >>> drivers/staging/media/sunxi/cedrus/TODO | 7 +++ >>> drivers/staging/media/sunxi/cedrus/cedrus.c | 15 --- >>> 2 files changed, 19 insertions(+), 3 deletions(-) >>> create mode 100644 drivers/staging/media/sunxi/cedrus/TODO >>> >> >> So close... >> >> When compiling under e.g. intel I get errors since it doesn't know about >> the sunxi_sram_claim/release function and the PHYS_PFN_OFFSET define. >> >> Is it possible to add stub functions to linux/soc/sunxi/sunxi_sram.h >> if CONFIG_SUNXI_SRAM is not defined? That would be the best fix for that. >> >> The use of PHYS_PFN_OFFSET is weird: are you sure this is the right >> way? I see that drivers/of/device.c also sets dev->dma_pfn_offset, which >> makes me wonder if this information shouldn't come from the device tree. >> >> You are the only driver that uses this define directly, which makes me >> suspicious. > > On Allwinner platforms, some devices do DMA directly on the memory BUS > with the DRAM controller. In such cases, the DRAM has no offset. In all > other cases where the DMA goes through the common system bus and the DRAM > offset is either 0x4000 or 0x2000, depending on the SoC. Since the > former case is not described in the device tree (this is being worked on > by Maxime BTW), the dma_pfn_offset is not the value it should be. AFAIK > only the display and media subsystems (VPU, camera, TS) are wired this > way. > > In drivers/gpu/drm/sun4i/sun4i_backend.c (the display driver) we use > PHYS_OFFSET, which is pretty much the same thing. > OK, in that case just put #ifdef PHYS_PFN_OFFSET around that line together with a comment that this will eventually come from the device tree. Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: rtl8188eu: remove unnecessary parentheses in rtw_led.c
Remove unnecessary parentheses from conditionals.
Also clears 'Alignment should match open parenthesis'
checkpatch issue.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_led.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_led.c
b/drivers/staging/rtl8188eu/core/rtw_led.c
index 217a1aaab8a1..d51494eb11ab 100644
--- a/drivers/staging/rtl8188eu/core/rtw_led.c
+++ b/drivers/staging/rtl8188eu/core/rtw_led.c
@@ -18,7 +18,7 @@ static void BlinkTimerCallback(struct timer_list *t)
struct LED_871x *pLed = from_timer(pLed, t, BlinkTimer);
struct adapter *padapter = pLed->padapter;
- if ((padapter->bSurpriseRemoved) || (padapter->bDriverStopped))
+ if (padapter->bSurpriseRemoved || padapter->bDriverStopped)
return;
schedule_work(&pLed->BlinkWorkItem);
@@ -460,7 +460,7 @@ void BlinkHandler(struct LED_871x *pLed)
{
struct adapter *padapter = pLed->padapter;
- if ((padapter->bSurpriseRemoved) || (padapter->bDriverStopped))
+ if (padapter->bSurpriseRemoved || padapter->bDriverStopped)
return;
SwLedBlink1(pLed);
@@ -468,8 +468,8 @@ void BlinkHandler(struct LED_871x *pLed)
void LedControl8188eu(struct adapter *padapter, enum LED_CTL_MODE LedAction)
{
- if ((padapter->bSurpriseRemoved) || (padapter->bDriverStopped) ||
- (!padapter->hw_init_completed))
+ if (padapter->bSurpriseRemoved || padapter->bDriverStopped ||
+ !padapter->hw_init_completed)
return;
if ((padapter->pwrctrlpriv.rf_pwrstate != rf_on &&
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: rtl8188eu: refactor SwLedControlMode1()
Refactor switch cases in SwLedControlMode1() to reduce
indentation level. Also clears line over 80 characters
checkpatch warnings.
Suggested-by: Joe Perches
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_led.c | 223 ---
1 file changed, 113 insertions(+), 110 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_led.c
b/drivers/staging/rtl8188eu/core/rtw_led.c
index cbef871a7679..217a1aaab8a1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_led.c
+++ b/drivers/staging/rtl8188eu/core/rtw_led.c
@@ -245,131 +245,134 @@ static void SwLedControlMode1(struct adapter *padapter,
enum LED_CTL_MODE LedAct
case LED_CTL_POWER_ON:
case LED_CTL_START_TO_LINK:
case LED_CTL_NO_LINK:
- if (!pLed->bLedNoLinkBlinkInProgress) {
- if (pLed->CurrLedState == LED_BLINK_SCAN ||
IS_LED_WPS_BLINKING(pLed))
- return;
- if (pLed->bLedLinkBlinkInProgress) {
- del_timer_sync(&pLed->BlinkTimer);
- pLed->bLedLinkBlinkInProgress = false;
- }
- if (pLed->bLedBlinkInProgress) {
- del_timer_sync(&pLed->BlinkTimer);
- pLed->bLedBlinkInProgress = false;
- }
-
- pLed->bLedNoLinkBlinkInProgress = true;
- pLed->CurrLedState = LED_BLINK_SLOWLY;
- if (pLed->bLedOn)
- pLed->BlinkingLedState = RTW_LED_OFF;
- else
- pLed->BlinkingLedState = RTW_LED_ON;
- mod_timer(&pLed->BlinkTimer, jiffies +
-
msecs_to_jiffies(LED_BLINK_NO_LINK_INTERVAL_ALPHA));
+ if (pLed->bLedNoLinkBlinkInProgress)
+ break;
+ if (pLed->CurrLedState == LED_BLINK_SCAN ||
+ IS_LED_WPS_BLINKING(pLed))
+ return;
+ if (pLed->bLedLinkBlinkInProgress) {
+ del_timer_sync(&pLed->BlinkTimer);
+ pLed->bLedLinkBlinkInProgress = false;
+ }
+ if (pLed->bLedBlinkInProgress) {
+ del_timer_sync(&pLed->BlinkTimer);
+ pLed->bLedBlinkInProgress = false;
}
+ pLed->bLedNoLinkBlinkInProgress = true;
+ pLed->CurrLedState = LED_BLINK_SLOWLY;
+ if (pLed->bLedOn)
+ pLed->BlinkingLedState = RTW_LED_OFF;
+ else
+ pLed->BlinkingLedState = RTW_LED_ON;
+ mod_timer(&pLed->BlinkTimer, jiffies +
+ msecs_to_jiffies(LED_BLINK_NO_LINK_INTERVAL_ALPHA));
break;
case LED_CTL_LINK:
- if (!pLed->bLedLinkBlinkInProgress) {
- if (pLed->CurrLedState == LED_BLINK_SCAN ||
IS_LED_WPS_BLINKING(pLed))
- return;
- if (pLed->bLedNoLinkBlinkInProgress) {
- del_timer_sync(&pLed->BlinkTimer);
- pLed->bLedNoLinkBlinkInProgress = false;
- }
- if (pLed->bLedBlinkInProgress) {
- del_timer_sync(&pLed->BlinkTimer);
- pLed->bLedBlinkInProgress = false;
- }
- pLed->bLedLinkBlinkInProgress = true;
- pLed->CurrLedState = LED_BLINK_NORMAL;
- if (pLed->bLedOn)
- pLed->BlinkingLedState = RTW_LED_OFF;
- else
- pLed->BlinkingLedState = RTW_LED_ON;
- mod_timer(&pLed->BlinkTimer, jiffies +
-
msecs_to_jiffies(LED_BLINK_LINK_INTERVAL_ALPHA));
+ if (pLed->bLedLinkBlinkInProgress)
+ break;
+ if (pLed->CurrLedState == LED_BLINK_SCAN ||
+ IS_LED_WPS_BLINKING(pLed))
+ return;
+ if (pLed->bLedNoLinkBlinkInProgress) {
+ del_timer_sync(&pLed->BlinkTimer);
+ pLed->bLedNoLinkBlinkInProgress = false;
+ }
+ if (pLed->bLedBlinkInProgress) {
+ del_timer_sync(&pLed->BlinkTimer);
+ pLed->bLedBlinkInProgress = false;
}
+ pLed->bLedLinkBlinkInProgress = true;
+ pLed->CurrLedState = LED_BLINK_NORMAL;
+ if (pLed->bLedOn)
+ pLed->BlinkingLedState = RTW_LED_OFF;
+ else
+ pLed->BlinkingLedState = RTW_LED_ON;
+ mod_timer(&pLed->Bli
[PATCH 3/3] staging: rtl8188eu: fix lines over 80 characters in rtw_led.c
Wrap lines over 80 characters where appropriate to
clear checkpatch warnings.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_led.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_led.c
b/drivers/staging/rtl8188eu/core/rtw_led.c
index d51494eb11ab..98106e77a9f6 100644
--- a/drivers/staging/rtl8188eu/core/rtw_led.c
+++ b/drivers/staging/rtl8188eu/core/rtw_led.c
@@ -95,10 +95,12 @@ static void SwLedBlink1(struct LED_871x *pLed)
/* Change LED according to BlinkingLedState specified. */
if (pLed->BlinkingLedState == RTW_LED_ON) {
SwLedOn(padapter, pLed);
- RT_TRACE(_module_rtl8712_led_c_, _drv_info_, ("Blinktimes (%d):
turn on\n", pLed->BlinkTimes));
+ RT_TRACE(_module_rtl8712_led_c_, _drv_info_,
+("Blinktimes (%d): turn on\n", pLed->BlinkTimes));
} else {
SwLedOff(padapter, pLed);
- RT_TRACE(_module_rtl8712_led_c_, _drv_info_, ("Blinktimes (%d):
turn off\n", pLed->BlinkTimes));
+ RT_TRACE(_module_rtl8712_led_c_, _drv_info_,
+("Blinktimes (%d): turn off\n", pLed->BlinkTimes));
}
if (padapter->pwrctrlpriv.rf_pwrstate != rf_on) {
@@ -449,7 +451,8 @@ static void SwLedControlMode1(struct adapter *padapter,
enum LED_CTL_MODE LedAct
break;
}
- RT_TRACE(_module_rtl8712_led_c_, _drv_info_, ("Led %d\n",
pLed->CurrLedState));
+ RT_TRACE(_module_rtl8712_led_c_, _drv_info_,
+("Led %d\n", pLed->CurrLedState));
}
/* */
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: android: ion: Fix compilation warning
Label unlock is defined but not used
Signed-off-by: Alexey Skidanov
---
drivers/staging/android/ion/ion.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 5fa5363..080ff1c 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -341,17 +341,14 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
{
struct ion_buffer *buffer = dmabuf->priv;
struct ion_dma_buf_attachment *a;
- int ret = 0;
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
direction);
}
-
-unlock:
mutex_unlock(&buffer->lock);
- return ret;
+ return 0;
}
static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
vadgknrwzbfiosw
ixbs___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ion: Fix compilation warning
On Sat, Sep 8, 2018 at 1:33 PM, Alexey Skidanov wrote: > Label unlock is defined but not used You are also removing the variable 'ret', which is a different change. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ion: Fix compilation warning
On Sat, Sep 08, 2018 at 02:04:06PM -0300, Fabio Estevam wrote: > On Sat, Sep 8, 2018 at 1:33 PM, Alexey Skidanov > wrote: > > Label unlock is defined but not used > > You are also removing the variable 'ret', which is a different change. I feel like it's fine. It doesn't make the patch harder to review. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ion: Fix compilation warning
On Sat, Sep 08, 2018 at 07:33:40PM +0300, Alexey Skidanov wrote: > Label unlock is defined but not used > > Signed-off-by: Alexey Skidanov There is no Fixes tag. I don't understand how the compile warning was added in the first place? The code in linux-next from Friday doesn't match. What the heck is going on? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ion: Fix compilation warning
On 09/08/2018 09:42 PM, Dan Carpenter wrote: > On Sat, Sep 08, 2018 at 07:33:40PM +0300, Alexey Skidanov wrote: >> Label unlock is defined but not used >> >> Signed-off-by: Alexey Skidanov > > There is no Fixes tag. I don't understand how the compile warning was > added in the first place? The code in linux-next from Friday doesn't > match. Sorry, you are correct. It's my fault. Thanks. > > What the heck is going on? > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] Follow-up patches for Cedrus v9
Hi, Le samedi 08 septembre 2018 à 13:24 +0200, Hans Verkuil a écrit : > On 09/08/2018 12:22 PM, Chen-Yu Tsai wrote: > > On Sat, Sep 8, 2018 at 6:06 PM Hans Verkuil wrote: > > > > > > On 09/07/2018 06:33 PM, Paul Kocialkowski wrote: > > > > This brings the requested modifications on top of version 9 of the > > > > Cedrus VPU driver, that implements stateless video decoding using the > > > > Request API. > > > > > > > > Paul Kocialkowski (2): > > > > media: cedrus: Fix error reporting in request validation > > > > media: cedrus: Add TODO file with tasks to complete before unstaging > > > > > > > > drivers/staging/media/sunxi/cedrus/TODO | 7 +++ > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 15 --- > > > > 2 files changed, 19 insertions(+), 3 deletions(-) > > > > create mode 100644 drivers/staging/media/sunxi/cedrus/TODO > > > > > > > > > > So close... > > > > > > When compiling under e.g. intel I get errors since it doesn't know about > > > the sunxi_sram_claim/release function and the PHYS_PFN_OFFSET define. > > > > > > Is it possible to add stub functions to linux/soc/sunxi/sunxi_sram.h > > > if CONFIG_SUNXI_SRAM is not defined? That would be the best fix for that. > > > > > > The use of PHYS_PFN_OFFSET is weird: are you sure this is the right > > > way? I see that drivers/of/device.c also sets dev->dma_pfn_offset, which > > > makes me wonder if this information shouldn't come from the device tree. > > > > > > You are the only driver that uses this define directly, which makes me > > > suspicious. > > > > On Allwinner platforms, some devices do DMA directly on the memory BUS > > with the DRAM controller. In such cases, the DRAM has no offset. In all > > other cases where the DMA goes through the common system bus and the DRAM > > offset is either 0x4000 or 0x2000, depending on the SoC. Since the > > former case is not described in the device tree (this is being worked on > > by Maxime BTW), the dma_pfn_offset is not the value it should be. AFAIK > > only the display and media subsystems (VPU, camera, TS) are wired this > > way. > > > > In drivers/gpu/drm/sun4i/sun4i_backend.c (the display driver) we use > > PHYS_OFFSET, which is pretty much the same thing. > > > > OK, in that case just put #ifdef PHYS_PFN_OFFSET around that line together > with a comment that this will eventually come from the device tree. That seems fine, although I'm less certain about what to do for the SRAM situation. Other drivers that use SUNXI_SRAM have a Kconfig select on it (that Cedrus lacks). Provided that the SRAM driver builds fine for non-sunxi configs, bringing-in that select would remove the need for dummy functions and also ensure that the actual implementation is always used on sunxi. Otherwise, there'd be a risk of having the dummy functions used (if the SRAM driver is not explicitly selected in the config), causing a hang when accessing the VPU. What do you think? Cheers, Paul -- Developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Collaboration
Hello there, I hope this message reaches you in good spirit. My name is Elliot Matare. I got your contact from an online business directory as a reputable industrialist with high integrity. I have a proposition that I think will be of great interest to you. I am the brother in law of a major opposition leader in Mozambique (a South Eastern African Regional country) who is presently at logger head with the ruling party over demands for better integration of its supporters into the police and military as a precondition of a peace deal. The main reason for contacting you is to propose a business cooperation that will be of mutual benefit to both of us and requiring absolute trust and total confidentiality. To get down to brass tacks, we need you to accommodate a large volume of funds for investment into your industrial sector or any other viable sector in your country. We need a foreigner without any prior link to our country for this task for security reasons. Of course, you will be handsomely rewarded for your efforts as well. If you are interested in this proposition, kindly respond back to me so I can give you further details and what is required for our trust. We will also negotiate an appropriate compensation for your efforts. Yours faithfully, Elliot Matare ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: android: ion: Add per-heap counters
The heap statistics have been removed and currently even basics statistics
are missing.
This patch creates per heap debugfs directory /sys/kernel/debug/
and adds two counters - the number of allocated buffers and number of
allocated bytes.
Signed-off-by: Alexey Skidanov
---
drivers/staging/android/ion/ion.c | 40 +++
drivers/staging/android/ion/ion.h | 3 ++-
2 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 9907332..62335b9 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -95,6 +95,9 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
goto err1;
}
+ heap->num_of_buffers++;
+ heap->num_of_alloc_bytes += len;
+
INIT_LIST_HEAD(&buffer->attachments);
mutex_init(&buffer->lock);
mutex_lock(&dev->buffer_lock);
@@ -528,6 +531,8 @@ void ion_device_add_heap(struct ion_heap *heap)
{
struct ion_device *dev = internal_dev;
int ret;
+ struct dentry *heap_root;
+ char debug_name[64];
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -546,6 +551,33 @@ void ion_device_add_heap(struct ion_heap *heap)
}
heap->dev = dev;
+ heap->num_of_buffers = 0;
+ heap->num_of_alloc_bytes = 0;
+
+ /* Create heap root directory. If creation is failed, we may continue */
+ heap_root = debugfs_create_dir(heap->name, dev->debug_root);
+ if (!IS_ERR_OR_NULL(heap_root)) {
+ debugfs_create_u64("num_of_buffers",
+ 0444, heap_root,
+ &heap->num_of_buffers);
+ debugfs_create_u64("num_of_alloc_bytes",
+ 0444,
+ heap_root,
+ &heap->num_of_alloc_bytes);
+
+ if (heap->shrinker.count_objects &&
+ heap->shrinker.scan_objects) {
+ snprintf(debug_name, 64, "%s_shrink", heap->name);
+ debugfs_create_file(debug_name,
+ 0644,
+ heap_root,
+ heap,
+ &debug_shrink_fops);
+ }
+ } else {
+ pr_err("%s: Failed to create heap dir in debugfs\n", __func__);
+ }
+
down_write(&dev->lock);
heap->id = heap_id++;
/*
@@ -555,14 +587,6 @@ void ion_device_add_heap(struct ion_heap *heap)
plist_node_init(&heap->node, -heap->id);
plist_add(&heap->node, &dev->heaps);
- if (heap->shrinker.count_objects && heap->shrinker.scan_objects) {
- char debug_name[64];
-
- snprintf(debug_name, 64, "%s_shrink", heap->name);
- debugfs_create_file(debug_name, 0644, dev->debug_root,
- heap, &debug_shrink_fops);
- }
-
dev->heap_cnt++;
up_write(&dev->lock);
}
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 16cbd38..8f1326a 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -179,9 +179,10 @@ struct ion_heap {
spinlock_t free_lock;
wait_queue_head_t waitqueue;
struct task_struct *task;
-
int (*debug_show)(struct ion_heap *heap, struct seq_file *s,
void *unused);
+ u64 num_of_buffers;
+ u64 num_of_alloc_bytes;
};
/**
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
