Re: [PATCH v2 2/4] media: cedrus: hevc: Add support for scaling matrix
On 1/7/20 6:10 PM, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 07. januar 2020 ob 16:01:16 CET je Hans Verkuil napisal(a):
>> On 12/13/19 5:04 PM, Jernej Skrabec wrote:
>>> HEVC frames may use scaling list feature. Add support for it.
>>>
>>> Signed-off-by: Jernej Skrabec
>>> ---
>>>
>>> drivers/staging/media/sunxi/cedrus/cedrus.c | 7 ++
>>> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
>>> .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 +
>>> .../staging/media/sunxi/cedrus/cedrus_h265.c | 70 ++-
>>> .../staging/media/sunxi/cedrus/cedrus_regs.h | 2 +
>>> 5 files changed, 81 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> b/drivers/staging/media/sunxi/cedrus/cedrus.c index
>>> c6ddd46eff82..bf68bc6b20c8 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
>>> @@ -116,6 +116,13 @@ static const struct cedrus_control cedrus_controls[]
>>> = {>
>>> .codec = CEDRUS_CODEC_H265,
>>> .required = true,
>>>
>>> },
>>>
>>> + {
>>> + .cfg = {
>>> + .id =
> V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX,
>>> + },
>>> + .codec = CEDRUS_CODEC_H265,
>>> + .required = true,
>>
>> Should this be true? This means that existing applications are now
>> suddenly required to always pass the scaling matrix for every buffer.
>>
>> Especially since the commit log says: 'HEVC frames *may* use scaling list
>> feature', indicating that this is an optional feature.
>
> True. Can you fix this when applying if this is the only issue?
I'll do that.
Regards,
Hans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: hantro: remove a pointless NULL check
This can't be NULL and we've already dereferenced it so let's remove the check. Signed-off-by: Dan Carpenter --- drivers/staging/media/hantro/hantro_v4l2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c index 85af1b96fd34..0198bcda26b7 100644 --- a/drivers/staging/media/hantro/hantro_v4l2.c +++ b/drivers/staging/media/hantro/hantro_v4l2.c @@ -688,7 +688,7 @@ static int hantro_start_streaming(struct vb2_queue *q, unsigned int count) return ret; err_codec_exit: - if (ctx->codec_ops && ctx->codec_ops->exit) + if (ctx->codec_ops->exit) ctx->codec_ops->exit(ctx); return ret; } -- 2.11.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] vme: bridges: reduce stack usage
With CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, the stack usage in vme_fake
grows above the warning limit:
drivers/vme/bridges/vme_fake.c: In function 'fake_master_read':
drivers/vme/bridges/vme_fake.c:610:1: error: the frame size of 1160 bytes is
larger than 1024 bytes [-Werror=frame-larger-than=]
drivers/vme/bridges/vme_fake.c: In function 'fake_master_write':
drivers/vme/bridges/vme_fake.c:797:1: error: the frame size of 1160 bytes is
larger than 1024 bytes [-Werror=frame-larger-than=]
The problem is that in some configurations, each call to
fake_vmereadX() puts another variable on the stack.
Reduce the amount of inlining to get back to the previous state,
with no function using more than 200 bytes each.
Fixes: mmtom ("init/Kconfig: enable -O3 for all arches")
Signed-off-by: Arnd Bergmann
---
drivers/vme/bridges/vme_fake.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/vme/bridges/vme_fake.c b/drivers/vme/bridges/vme_fake.c
index 3208a4409e44..6a1bc284f297 100644
--- a/drivers/vme/bridges/vme_fake.c
+++ b/drivers/vme/bridges/vme_fake.c
@@ -414,8 +414,9 @@ static void fake_lm_check(struct fake_driver *bridge,
unsigned long long addr,
}
}
-static u8 fake_vmeread8(struct fake_driver *bridge, unsigned long long addr,
- u32 aspace, u32 cycle)
+static noinline_for_stack u8 fake_vmeread8(struct fake_driver *bridge,
+ unsigned long long addr,
+ u32 aspace, u32 cycle)
{
u8 retval = 0xff;
int i;
@@ -446,8 +447,9 @@ static u8 fake_vmeread8(struct fake_driver *bridge,
unsigned long long addr,
return retval;
}
-static u16 fake_vmeread16(struct fake_driver *bridge, unsigned long long addr,
- u32 aspace, u32 cycle)
+static noinline_for_stack u16 fake_vmeread16(struct fake_driver *bridge,
+unsigned long long addr,
+u32 aspace, u32 cycle)
{
u16 retval = 0x;
int i;
@@ -478,8 +480,9 @@ static u16 fake_vmeread16(struct fake_driver *bridge,
unsigned long long addr,
return retval;
}
-static u32 fake_vmeread32(struct fake_driver *bridge, unsigned long long addr,
- u32 aspace, u32 cycle)
+static noinline_for_stack u32 fake_vmeread32(struct fake_driver *bridge,
+unsigned long long addr,
+u32 aspace, u32 cycle)
{
u32 retval = 0x;
int i;
@@ -609,8 +612,9 @@ static ssize_t fake_master_read(struct vme_master_resource
*image, void *buf,
return retval;
}
-static void fake_vmewrite8(struct fake_driver *bridge, u8 *buf,
- unsigned long long addr, u32 aspace, u32 cycle)
+static noinline_for_stack void fake_vmewrite8(struct fake_driver *bridge,
+ u8 *buf, unsigned long long addr,
+ u32 aspace, u32 cycle)
{
int i;
unsigned long long start, end, offset;
@@ -639,8 +643,9 @@ static void fake_vmewrite8(struct fake_driver *bridge, u8
*buf,
}
-static void fake_vmewrite16(struct fake_driver *bridge, u16 *buf,
- unsigned long long addr, u32 aspace, u32 cycle)
+static noinline_for_stack void fake_vmewrite16(struct fake_driver *bridge,
+ u16 *buf, unsigned long long
addr,
+ u32 aspace, u32 cycle)
{
int i;
unsigned long long start, end, offset;
@@ -669,8 +674,9 @@ static void fake_vmewrite16(struct fake_driver *bridge, u16
*buf,
}
-static void fake_vmewrite32(struct fake_driver *bridge, u32 *buf,
- unsigned long long addr, u32 aspace, u32 cycle)
+static noinline_for_stack void fake_vmewrite32(struct fake_driver *bridge,
+ u32 *buf, unsigned long long
addr,
+ u32 aspace, u32 cycle)
{
int i;
unsigned long long start, end, offset;
--
2.20.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/4] media: cedrus: hevc: Add support for scaling matrix
Hi!
Dne torek, 07. januar 2020 ob 16:01:16 CET je Hans Verkuil napisal(a):
> On 12/13/19 5:04 PM, Jernej Skrabec wrote:
> > HEVC frames may use scaling list feature. Add support for it.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 ++
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 +
> > .../staging/media/sunxi/cedrus/cedrus_h265.c | 70 ++-
> > .../staging/media/sunxi/cedrus/cedrus_regs.h | 2 +
> > 5 files changed, 81 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus.c index
> > c6ddd46eff82..bf68bc6b20c8 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@ -116,6 +116,13 @@ static const struct cedrus_control cedrus_controls[]
> > = {>
> > .codec = CEDRUS_CODEC_H265,
> > .required = true,
> >
> > },
> >
> > + {
> > + .cfg = {
> > + .id =
V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX,
> > + },
> > + .codec = CEDRUS_CODEC_H265,
> > + .required = true,
>
> Should this be true? This means that existing applications are now
> suddenly required to always pass the scaling matrix for every buffer.
>
> Especially since the commit log says: 'HEVC frames *may* use scaling list
> feature', indicating that this is an optional feature.
True. Can you fix this when applying if this is the only issue?
Best regards,
Jernej
>
> Regards,
>
> Hans
>
> > + },
> >
> > {
> >
> > .cfg = {
> >
> > .id =
V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE,
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 9676ab8a..d945f4f0ff2d 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -73,6 +73,7 @@ struct cedrus_h265_run {
> >
> > const struct v4l2_ctrl_hevc_sps *sps;
> > const struct v4l2_ctrl_hevc_pps *pps;
> > const struct v4l2_ctrl_hevc_slice_params*slice_params;
> >
> > + const struct v4l2_ctrl_hevc_scaling_matrix
*scaling_matrix;
> >
> > };
> >
> > struct cedrus_run {
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > 4a2fc33a1d79..327ed6c264dc 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -66,6 +66,8 @@ void cedrus_device_run(void *priv)
> >
> > V4L2_CID_MPEG_VIDEO_HEVC_PPS);
> >
> > run.h265.slice_params = cedrus_find_control_data(ctx,
> >
> > V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS);
> >
> > + run.h265.scaling_matrix = cedrus_find_control_data(ctx,
> > + V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX);
> >
> > break;
> >
> > default:
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c index
> > 6945dc74e1d7..888bfd5ca224 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> > @@ -220,6 +220,69 @@ static void cedrus_h265_pred_weight_write(struct
> > cedrus_dev *dev,>
> > }
> >
> > }
> >
> > +static void cedrus_h265_write_scaling_list(struct cedrus_ctx *ctx,
> > + struct cedrus_run
*run)
> > +{
> > + const struct v4l2_ctrl_hevc_scaling_matrix *scaling;
> > + struct cedrus_dev *dev = ctx->dev;
> > + u32 i, j, k, val;
> > +
> > + scaling = run->h265.scaling_matrix;
> > +
> > + cedrus_write(dev, VE_DEC_H265_SCALING_LIST_DC_COEF0,
> > +(scaling->scaling_list_dc_coef_32x32[1] << 24) |
> > +(scaling->scaling_list_dc_coef_32x32[0] << 16) |
> > +(scaling->scaling_list_dc_coef_16x16[1] << 8) |
> > +(scaling->scaling_list_dc_coef_16x16[0] << 0));
> > +
> > + cedrus_write(dev, VE_DEC_H265_SCALING_LIST_DC_COEF1,
> > +(scaling->scaling_list_dc_coef_16x16[5] << 24) |
> > +(scaling->scaling_list_dc_coef_16x16[4] << 16) |
> > +(scaling->scaling_list_dc_coef_16x16[3] << 8) |
> > +(scaling->scaling_list_dc_coef_16x16[2] << 0));
> > +
> > + cedrus_h265_sram_write_offset(dev,
> > VE_DEC_H265_SRAM_OFFSET_SCALING_LISTS); +
> > + for (i = 0; i < 6; i++)
> > + for (j = 0; j < 8; j++)
> > + for (k = 0; k < 8; k += 4) {
> > + val = ((u32)scaling-
>scaling_list_8x8[i][j + (k + 3) * 8] << 24)
Re: [PATCH v2 2/4] media: cedrus: hevc: Add support for scaling matrix
On 12/13/19 5:04 PM, Jernej Skrabec wrote:
> HEVC frames may use scaling list feature. Add support for it.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 7 ++
> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 +
> .../staging/media/sunxi/cedrus/cedrus_h265.c | 70 ++-
> .../staging/media/sunxi/cedrus/cedrus_regs.h | 2 +
> 5 files changed, 81 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index c6ddd46eff82..bf68bc6b20c8 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -116,6 +116,13 @@ static const struct cedrus_control cedrus_controls[] = {
> .codec = CEDRUS_CODEC_H265,
> .required = true,
> },
> + {
> + .cfg = {
> + .id = V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX,
> + },
> + .codec = CEDRUS_CODEC_H265,
> + .required = true,
Should this be true? This means that existing applications are now
suddenly required to always pass the scaling matrix for every buffer.
Especially since the commit log says: 'HEVC frames *may* use scaling list
feature', indicating that this is an optional feature.
Regards,
Hans
> + },
> {
> .cfg = {
> .id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE,
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> b/drivers/staging/media/sunxi/cedrus/cedrus.h
> index 9676ab8a..d945f4f0ff2d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -73,6 +73,7 @@ struct cedrus_h265_run {
> const struct v4l2_ctrl_hevc_sps *sps;
> const struct v4l2_ctrl_hevc_pps *pps;
> const struct v4l2_ctrl_hevc_slice_params*slice_params;
> + const struct v4l2_ctrl_hevc_scaling_matrix *scaling_matrix;
> };
>
> struct cedrus_run {
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index 4a2fc33a1d79..327ed6c264dc 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -66,6 +66,8 @@ void cedrus_device_run(void *priv)
> V4L2_CID_MPEG_VIDEO_HEVC_PPS);
> run.h265.slice_params = cedrus_find_control_data(ctx,
> V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS);
> + run.h265.scaling_matrix = cedrus_find_control_data(ctx,
> + V4L2_CID_MPEG_VIDEO_HEVC_SCALING_MATRIX);
> break;
>
> default:
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> index 6945dc74e1d7..888bfd5ca224 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
> @@ -220,6 +220,69 @@ static void cedrus_h265_pred_weight_write(struct
> cedrus_dev *dev,
> }
> }
>
> +static void cedrus_h265_write_scaling_list(struct cedrus_ctx *ctx,
> +struct cedrus_run *run)
> +{
> + const struct v4l2_ctrl_hevc_scaling_matrix *scaling;
> + struct cedrus_dev *dev = ctx->dev;
> + u32 i, j, k, val;
> +
> + scaling = run->h265.scaling_matrix;
> +
> + cedrus_write(dev, VE_DEC_H265_SCALING_LIST_DC_COEF0,
> + (scaling->scaling_list_dc_coef_32x32[1] << 24) |
> + (scaling->scaling_list_dc_coef_32x32[0] << 16) |
> + (scaling->scaling_list_dc_coef_16x16[1] << 8) |
> + (scaling->scaling_list_dc_coef_16x16[0] << 0));
> +
> + cedrus_write(dev, VE_DEC_H265_SCALING_LIST_DC_COEF1,
> + (scaling->scaling_list_dc_coef_16x16[5] << 24) |
> + (scaling->scaling_list_dc_coef_16x16[4] << 16) |
> + (scaling->scaling_list_dc_coef_16x16[3] << 8) |
> + (scaling->scaling_list_dc_coef_16x16[2] << 0));
> +
> + cedrus_h265_sram_write_offset(dev,
> VE_DEC_H265_SRAM_OFFSET_SCALING_LISTS);
> +
> + for (i = 0; i < 6; i++)
> + for (j = 0; j < 8; j++)
> + for (k = 0; k < 8; k += 4) {
> + val = ((u32)scaling->scaling_list_8x8[i][j + (k
> + 3) * 8] << 24) |
> + ((u32)scaling->scaling_list_8x8[i][j + (k
> + 2) * 8] << 16) |
> + ((u32)scaling->scaling_list_8x8[i][j + (k
> + 1) * 8] << 8) |
> + scaling->scaling_list_8x8[i][j + k * 8];
> + cedrus_write(dev, VE_DEC_H265_SRAM_DATA, val);
> + }
> +
> + for (i = 0; i <
[PATCH v4] drivers/staging/exfat/exfat_super.c: Clean up ffsCamelCase function names
Rename every instance of to
in file exfat_super.c. Fix resulting overlong lines.
Co-developed-by: Johannes Weidner
Signed-off-by: Johannes Weidner
Signed-off-by: Julian Preis
---
Changes in v4:
- Resolve name conflicts for functions create_file, move_file, remove_file and
create_dir by adding a "ffs_" prefix for these four functions.
Changes in v3:
- Change renaming from to
Changes in v2:
- Add email recipients according to get_maintainer.pl
- Add patch versions
- Use in-reply-to
---
drivers/staging/exfat/exfat_super.c | 97 +++--
1 file changed, 49 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/exfat/exfat_super.c
b/drivers/staging/exfat/exfat_super.c
index 744344a2521c..9561144972b7 100644
--- a/drivers/staging/exfat/exfat_super.c
+++ b/drivers/staging/exfat/exfat_super.c
@@ -343,7 +343,7 @@ static inline void exfat_save_attr(struct inode *inode, u32
attr)
EXFAT_I(inode)->fid.attr = attr & (ATTR_RWMASK | ATTR_READONLY);
}
-static int ffsMountVol(struct super_block *sb)
+static int mount_vol(struct super_block *sb)
{
int i, ret;
struct pbr_sector_t *p_pbr;
@@ -439,7 +439,7 @@ static int ffsMountVol(struct super_block *sb)
return ret;
}
-static int ffsUmountVol(struct super_block *sb)
+static int umount_vol(struct super_block *sb)
{
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
int err = 0;
@@ -479,7 +479,7 @@ static int ffsUmountVol(struct super_block *sb)
return err;
}
-static int ffsGetVolInfo(struct super_block *sb, struct vol_info_t *info)
+static int get_vol_info(struct super_block *sb, struct vol_info_t *info)
{
int err = 0;
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
@@ -509,7 +509,7 @@ static int ffsGetVolInfo(struct super_block *sb, struct
vol_info_t *info)
return err;
}
-static int ffsSyncVol(struct super_block *sb, bool do_sync)
+static int sync_vol(struct super_block *sb, bool do_sync)
{
int err = 0;
struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info);
@@ -534,7 +534,7 @@ static int ffsSyncVol(struct super_block *sb, bool do_sync)
/* File Operation Functions*/
/*--*/
-static int ffsLookupFile(struct inode *inode, char *path, struct file_id_t
*fid)
+static int lookup_file(struct inode *inode, char *path, struct file_id_t *fid)
{
int ret, dentry, num_entries;
struct chain_t dir;
@@ -621,8 +621,8 @@ static int ffsLookupFile(struct inode *inode, char *path,
struct file_id_t *fid)
return ret;
}
-static int ffsCreateFile(struct inode *inode, char *path, u8 mode,
-struct file_id_t *fid)
+static int ffs_create_file(struct inode *inode, char *path, u8 mode,
+ struct file_id_t *fid)
{
struct chain_t dir;
struct uni_name_t uni_name;
@@ -662,8 +662,8 @@ static int ffsCreateFile(struct inode *inode, char *path,
u8 mode,
return ret;
}
-static int ffsReadFile(struct inode *inode, struct file_id_t *fid, void
*buffer,
- u64 count, u64 *rcount)
+static int read_file(struct inode *inode, struct file_id_t *fid, void *buffer,
+u64 count, u64 *rcount)
{
s32 offset, sec_offset, clu_offset;
u32 clu;
@@ -788,8 +788,8 @@ static int ffsReadFile(struct inode *inode, struct
file_id_t *fid, void *buffer,
return ret;
}
-static int ffsWriteFile(struct inode *inode, struct file_id_t *fid,
- void *buffer, u64 count, u64 *wcount)
+static int write_file(struct inode *inode, struct file_id_t *fid,
+ void *buffer, u64 count, u64 *wcount)
{
bool modified = false;
s32 offset, sec_offset, clu_offset;
@@ -1031,7 +1031,7 @@ static int ffsWriteFile(struct inode *inode, struct
file_id_t *fid,
return ret;
}
-static int ffsTruncateFile(struct inode *inode, u64 old_size, u64 new_size)
+static int truncate_file(struct inode *inode, u64 old_size, u64 new_size)
{
s32 num_clusters;
u32 last_clu = CLUSTER_32(0);
@@ -1167,8 +1167,8 @@ static void update_parent_info(struct file_id_t *fid,
}
}
-static int ffsMoveFile(struct inode *old_parent_inode, struct file_id_t *fid,
- struct inode *new_parent_inode, struct dentry
*new_dentry)
+static int ffs_move_file(struct inode *old_parent_inode, struct file_id_t *fid,
+struct inode *new_parent_inode,
+struct dentry *new_dentry)
{
s32 ret;
s32 dentry;
@@ -1296,7 +1296,7 @@ static int ffsMoveFile(struct inode *old_parent_inode,
struct file_id_t *fid,
return ret;
}
-static int ffsRemoveFile(struct inode *inode, struct file_id_t *fid)
+static int ffs_remove_file(struct inode *inode, struct file_id_t *fid)
{
s32 dentry;
int ret
Re: [PATCH v1 0/3] Tegra GPIO: Minor code clean up
On Tue, Jan 7, 2020 at 10:31 AM Bartosz Golaszewski wrote: > wt., 7 sty 2020 o 10:29 Linus Walleij napisał(a): > > > Ugh, I now noticed I responded to Thierry only after applying this to my > > > tree. > > > > > > Anyway, it shouldn't be a problem. I'll take more care next time. > > > > OK shall I drop the patches from my tree then? No big deal. > > > > If you're fine with this, sure! OK dropped them, hadn't even pushed the branch out yet. Soon reaching the top of my mailbox so I will be pushing the branches for the autobuilders and later tonight for-next. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 0/3] Tegra GPIO: Minor code clean up
wt., 7 sty 2020 o 10:29 Linus Walleij napisał(a): > > On Tue, Jan 7, 2020 at 9:25 AM Bartosz Golaszewski > wrote: > > > pon., 6 sty 2020 o 23:59 Linus Walleij > > napisał(a): > > > On Sun, Dec 15, 2019 at 7:31 PM Dmitry Osipenko wrote: > > > > > > > I was investigating why CPU hangs during of GPIO driver suspend and in > > > > the end it turned out that it is a Broadcom WiFi driver problem because > > > > it keeps OOB wake-interrupt enabled while WLAN interface is DOWN and > > > > this > > > > may cause a bit weird CPU hang on writing to INT_ENB register during of > > > > GPIO driver suspend. Meanwhile I also noticed that a few things could be > > > > improved in the driver, that's what this small series addresses. > > > > > > > > Dmitry Osipenko (3): > > > > gpio: tegra: Use generic readl_relaxed/writel_relaxed accessors > > > > gpio: tegra: Properly handle irq_set_irq_wake() error > > > > gpio: tegra: Use NOIRQ phase for suspend/resume > > > > > > All three patches applied with Thierry's review/test tag. > > > > > > Yours, > > > Linus Walleij > > > > Ugh, I now noticed I responded to Thierry only after applying this to my > > tree. > > > > Anyway, it shouldn't be a problem. I'll take more care next time. > > OK shall I drop the patches from my tree then? No big deal. > If you're fine with this, sure! Thanks a lot, Bart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 0/3] Tegra GPIO: Minor code clean up
On Tue, Jan 7, 2020 at 9:25 AM Bartosz Golaszewski wrote: > pon., 6 sty 2020 o 23:59 Linus Walleij napisał(a): > > On Sun, Dec 15, 2019 at 7:31 PM Dmitry Osipenko wrote: > > > > > I was investigating why CPU hangs during of GPIO driver suspend and in > > > the end it turned out that it is a Broadcom WiFi driver problem because > > > it keeps OOB wake-interrupt enabled while WLAN interface is DOWN and this > > > may cause a bit weird CPU hang on writing to INT_ENB register during of > > > GPIO driver suspend. Meanwhile I also noticed that a few things could be > > > improved in the driver, that's what this small series addresses. > > > > > > Dmitry Osipenko (3): > > > gpio: tegra: Use generic readl_relaxed/writel_relaxed accessors > > > gpio: tegra: Properly handle irq_set_irq_wake() error > > > gpio: tegra: Use NOIRQ phase for suspend/resume > > > > All three patches applied with Thierry's review/test tag. > > > > Yours, > > Linus Walleij > > Ugh, I now noticed I responded to Thierry only after applying this to my tree. > > Anyway, it shouldn't be a problem. I'll take more care next time. OK shall I drop the patches from my tree then? No big deal. Thanks, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 0/3] Tegra GPIO: Minor code clean up
pon., 6 sty 2020 o 23:59 Linus Walleij napisał(a): > > On Sun, Dec 15, 2019 at 7:31 PM Dmitry Osipenko wrote: > > > I was investigating why CPU hangs during of GPIO driver suspend and in > > the end it turned out that it is a Broadcom WiFi driver problem because > > it keeps OOB wake-interrupt enabled while WLAN interface is DOWN and this > > may cause a bit weird CPU hang on writing to INT_ENB register during of > > GPIO driver suspend. Meanwhile I also noticed that a few things could be > > improved in the driver, that's what this small series addresses. > > > > Dmitry Osipenko (3): > > gpio: tegra: Use generic readl_relaxed/writel_relaxed accessors > > gpio: tegra: Properly handle irq_set_irq_wake() error > > gpio: tegra: Use NOIRQ phase for suspend/resume > > All three patches applied with Thierry's review/test tag. > > Yours, > Linus Walleij Ugh, I now noticed I responded to Thierry only after applying this to my tree. Anyway, it shouldn't be a problem. I'll take more care next time. Bart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
