[PATCH v2] staging: fbtft: fixed format-string errors.
Added __printf attribute to declaration of fbtft_dbg_hex and fixed
mismatches between format-specifiers and arguments in several function
calls.
Signed-off-by: Jeremy Sowden
---
Since v1:
* fixed some mismatches that I missed but were picked up by the kbuild
test robot.
drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
drivers/staging/fbtft/fb_ra8875.c | 2 +-
drivers/staging/fbtft/fbtft-io.c | 12 ++--
drivers/staging/fbtft/fbtft.h | 1 +
drivers/staging/fbtft/fbtft_device.c | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 8f27bd8da17d..d4dca3ce4db0 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -406,7 +406,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset,
size_t len)
static int write(struct fbtft_par *par, void *buf, size_t len)
{
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
- "%s(len=%d): ", __func__, len);
+ "%s(len=%zu): ", __func__, len);
gpiod_set_value(par->RW, 0); /* set write mode */
diff --git a/drivers/staging/fbtft/fb_ra8875.c
b/drivers/staging/fbtft/fb_ra8875.c
index 70b37fc7fb66..398bdbf53c9a 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -24,7 +24,7 @@ static int write_spi(struct fbtft_par *par, void *buf, size_t
len)
struct spi_message m;
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
- "%s(len=%d): ", __func__, len);
+ "%s(len=%zu): ", __func__, len);
if (!par->spi) {
dev_err(par->info->device,
diff --git a/drivers/staging/fbtft/fbtft-io.c b/drivers/staging/fbtft/fbtft-io.c
index 38cdad6203ea..0863d257d762 100644
--- a/drivers/staging/fbtft/fbtft-io.c
+++ b/drivers/staging/fbtft/fbtft-io.c
@@ -14,7 +14,7 @@ int fbtft_write_spi(struct fbtft_par *par, void *buf, size_t
len)
struct spi_message m;
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
- "%s(len=%d): ", __func__, len);
+ "%s(len=%zu): ", __func__, len);
if (!par->spi) {
dev_err(par->info->device,
@@ -47,7 +47,7 @@ int fbtft_write_spi_emulate_9(struct fbtft_par *par, void
*buf, size_t len)
u64 val, dc, tmp;
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
- "%s(len=%d): ", __func__, len);
+ "%s(len=%zu): ", __func__, len);
if (!par->extra) {
dev_err(par->info->device, "%s: error: par->extra is NULL\n",
@@ -109,7 +109,7 @@ int fbtft_read_spi(struct fbtft_par *par, void *buf, size_t
len)
txbuf[0] = par->startbyte | 0x3;
t.tx_buf = txbuf;
fbtft_par_dbg_hex(DEBUG_READ, par, par->info->device, u8,
- txbuf, len, "%s(len=%d) txbuf => ",
+ txbuf, len, "%s(len=%zu) txbuf => ",
__func__, len);
}
@@ -117,7 +117,7 @@ int fbtft_read_spi(struct fbtft_par *par, void *buf, size_t
len)
spi_message_add_tail(&t, &m);
ret = spi_sync(par->spi, &m);
fbtft_par_dbg_hex(DEBUG_READ, par, par->info->device, u8, buf, len,
- "%s(len=%d) buf <= ", __func__, len);
+ "%s(len=%zu) buf <= ", __func__, len);
return ret;
}
@@ -136,7 +136,7 @@ int fbtft_write_gpio8_wr(struct fbtft_par *par, void *buf,
size_t len)
#endif
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
- "%s(len=%d): ", __func__, len);
+ "%s(len=%zu): ", __func__, len);
while (len--) {
data = *(u8 *)buf;
@@ -186,7 +186,7 @@ int fbtft_write_gpio16_wr(struct fbtft_par *par, void *buf,
size_t len)
#endif
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
- "%s(len=%d): ", __func__, len);
+ "%s(len=%zu): ", __func__, len);
while (len) {
data = *(u16 *)buf;
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 7fdd3b0851ef..9b6bdb62093d 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -238,6 +238,7 @@ struct fbtft_par {
/* fbtft-core.c */
int fbtft_write_buf_dc(struct fbtft_par *par, void *buf, size_t len, int dc);
+__printf(5, 6)
void fbtft_dbg_hex(const struct device *dev, int groupsize,
void *buf, size_t len, const char *fmt, ...);
struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
diff --git a/drivers/staging/fbtft/fbtft_device.c
b/drivers/staging/fbtft/fbtft_device.c
inde
Re: [PATCH v6 3/7] gpu: ipu-v3: ipu-ic: Fully describe colorspace conversions
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
> Only providing the input and output RGB/YUV space to the IC task init
> functions is not sufficient. To fully characterize a colorspace
> conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
> and quantization also need to be specified.
>
> Define a 'struct ipu_ic_colorspace' that includes all the above, and pass
> the input and output ipu_ic_colorspace to the IC task init functions.
>
> This allows to actually enforce the fact that the IC:
>
> - can only encode to/from YUV full range (follow-up patch will remove
> this restriction).
> - can only encode to/from RGB full range.
> - can only encode using BT.601 standard (follow-up patch will add
> Rec.709 encoding support).
> - cannot convert colorspaces from input to output, the
> input and output colorspace chromaticities must be the same.
>
> The determination of the CSC coefficients based on the input/output
> colorspace parameters are moved to a new function calc_csc_coeffs(),
> called by init_csc().
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/gpu/ipu-v3/ipu-ic.c | 136 +---
> drivers/gpu/ipu-v3/ipu-image-convert.c | 27 ++--
> drivers/staging/media/imx/imx-ic-prpencvf.c | 22 +++-
> include/video/imx-ipu-v3.h | 37 +-
> 4 files changed, 154 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index b63a2826b629..c4048c921801 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -146,8 +146,10 @@ struct ipu_ic {
> const struct ic_task_regoffs *reg;
> const struct ic_task_bitfields *bit;
>
> - enum ipu_color_space in_cs, g_in_cs;
> - enum ipu_color_space out_cs;
> + struct ipu_ic_colorspace in_cs;
> + struct ipu_ic_colorspace g_in_cs;
> + struct ipu_ic_colorspace out_cs;
> +
> bool graphics;
> bool rotation;
> bool in_use;
> @@ -235,42 +237,83 @@ static const struct ic_encode_coeff
> ic_encode_ycbcr2rgb_601 = {
> .scale = 2,
> };
>
> +static int calc_csc_coeffs(struct ipu_ic_priv *priv,
> +struct ic_encode_coeff *coeff_out,
> +const struct ipu_ic_colorspace *in,
> +const struct ipu_ic_colorspace *out)
> +{
> + bool inverse_encode;
> +
> + if (in->colorspace != out->colorspace) {
> + dev_err(priv->ipu->dev, "Cannot convert colorspaces\n");
> + return -ENOTSUPP;
> + }
I don't think this is useful enough to warrant having the colorspace
field in ipu_ic_colorspace. Let the caller make sure of this, same as
for xfer_func.
> + if (out->enc != V4L2_YCBCR_ENC_601) {
> + dev_err(priv->ipu->dev, "Only BT.601 encoding supported\n");
> + return -ENOTSUPP;
> + }
This is only important if out->cs is IPUV3_COLORSPACE_YUV, right? If the
output is RGB this field shouldn't matter.
> +
> + if ((in->cs == IPUV3_COLORSPACE_YUV &&
> + in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
> + (out->cs == IPUV3_COLORSPACE_YUV &&
> + out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
> + dev_err(priv->ipu->dev, "Limited range YUV not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + if ((in->cs == IPUV3_COLORSPACE_RGB &&
> + in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
> + (out->cs == IPUV3_COLORSPACE_RGB &&
> + out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
> + dev_err(priv->ipu->dev, "Limited range RGB not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + if (in->cs == out->cs) {
> + *coeff_out = ic_encode_identity;
> +
> + return 0;
> + }
> +
> + inverse_encode = (in->cs == IPUV3_COLORSPACE_YUV);
What does inverse_encode mean in this context?
> +
> + *coeff_out = inverse_encode ?
> + ic_encode_ycbcr2rgb_601 : ic_encode_rgb2ycbcr_601;
> +
> + return 0;
> +}
> +
> static int init_csc(struct ipu_ic *ic,
> - enum ipu_color_space inf,
> - enum ipu_color_space outf,
> + const struct ipu_ic_colorspace *in,
> + const struct ipu_ic_colorspace *out,
> int csc_index)
> {
> struct ipu_ic_priv *priv = ic->priv;
> - const struct ic_encode_coeff *coeff;
> + struct ic_encode_coeff coeff;
I understand this is a preparation for patch 5, but on its own this
introduces an unnecessary copy.
> u32 __iomem *base;
> const u16 (*c)[3];
> const u16 *a;
> u32 param;
> + int ret;
> +
> + ret = calc_csc_coeffs(priv, &coeff, in, out);
> + if (ret)
> + return ret;
>
> base = (u32 __iomem *)
> (priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
>
> - if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
> -
Re: [PATCH] media: imx: vdic: Fix wrong CSI group ID
On Fri, 2019-03-01 at 15:27 -0800, Steve Longerbeam wrote:
> The i.MX7 capture support forgot to change the group ID for the CSI
> to the IPU CSI in VDIC sub-device, it was left at the i.MX7 CSI
> group ID.
>
> Fixes: 67673ed55084 ("media: staging/imx: rearrange group id to take in
> account IPU")
>
> Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 4/9] staging:iio:ad7780: add chip ID values and mask
On 03/04, Ardelean, Alexandru wrote: On Sun, 2019-03-03 at 14:53 +, Jonathan Cameron wrote: [External] On Sun, 3 Mar 2019 11:01:09 -0300 Renato Lui Geh wrote: > On 03/01, Ardelean, Alexandru wrote: > > On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote: > > > > > > > > > The ad7780 supports both the ad778x and ad717x families. Each chip > > > has > > > a corresponding ID. This patch provides a mask for extracting ID > > > values > > > from the status bits and also macros for the correct values for the > > > ad7170, ad7171, ad7780 and ad7781. > > > > > > Signed-off-by: Renato Lui Geh > > > --- > > > drivers/staging/iio/adc/ad7780.c | 8 ++-- > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/staging/iio/adc/ad7780.c > > > b/drivers/staging/iio/adc/ad7780.c > > > index 56c49e28f432..ad7617a3a141 100644 > > > --- a/drivers/staging/iio/adc/ad7780.c > > > +++ b/drivers/staging/iio/adc/ad7780.c > > > @@ -26,10 +26,14 @@ > > > #define AD7780_RDY BIT(7) > > > #define AD7780_FILTER BIT(6) > > > #define AD7780_ERR BIT(5) > > > -#define AD7780_ID1 BIT(4) > > > -#define AD7780_ID0 BIT(3) > > > #define AD7780_GAINBIT(2) > > > > > > +#define AD7170_ID 0 > > > +#define AD7171_ID 1 > > > +#define AD7780_ID 1 > > > +#define AD7781_ID 0 > > > + > > > +#define AD7780_ID_MASK (BIT(3) | BIT(4)) > > > > This also doesn't have any functionality change. > > The AD7170_ID, AD7171_ID, AD7780_ID & AD7781_ID IDs are also unused > > (maybe > > in a later patch they are ?). > > They aren't. I added them following a previous review suggestion. > Should > I remove them? Can we check them? It's always useful to confirm that the device is the one you think it is. Then we can either use what is there with a suitable warning, or if that is tricky just fault out as the dt is giving us the wrong part number. J I guess `dev_warn_ratelimited()` could be used to make sure syslog isn't spammed-to-death when doing multiple conversions, and the ID isn't correct. Since these IDs are read after you get a sample, I'm a bit fearful of log- spam. I wouldn't throw an error in the ad7780_postprocess_sample() for this, but warning [with rate-limit] sounds reasonable. Looking at dev_warn_ratelimited's definition (and its use in other parts of the kernel), I see that we'd need the device to be stored somewhere (perhaps in ad7780_state?) in order for us to pass it as argument to dev_warn from within postprocess_sample. Should this be stored in ad7780_state? Or can I get the spi_device some other way? > > > > I would also leave the AD7780_ID1 & AD7780_ID0 definitions in place, > > since > > they're easier matched with the datasheet. > > > > > > > > #define AD7780_PATTERN_GOOD1 > > > #define AD7780_PATTERN_MASKGENMASK(1, 0) > > > -- > > > 2.21.0 > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6 3/7] gpu: ipu-v3: ipu-ic: Fully describe colorspace conversions
On 3/8/19 3:46 AM, Philipp Zabel wrote:
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
and quantization also need to be specified.
Define a 'struct ipu_ic_colorspace' that includes all the above, and pass
the input and output ipu_ic_colorspace to the IC task init functions.
This allows to actually enforce the fact that the IC:
- can only encode to/from YUV full range (follow-up patch will remove
this restriction).
- can only encode to/from RGB full range.
- can only encode using BT.601 standard (follow-up patch will add
Rec.709 encoding support).
- cannot convert colorspaces from input to output, the
input and output colorspace chromaticities must be the same.
The determination of the CSC coefficients based on the input/output
colorspace parameters are moved to a new function calc_csc_coeffs(),
called by init_csc().
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 136 +---
drivers/gpu/ipu-v3/ipu-image-convert.c | 27 ++--
drivers/staging/media/imx/imx-ic-prpencvf.c | 22 +++-
include/video/imx-ipu-v3.h | 37 +-
4 files changed, 154 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index b63a2826b629..c4048c921801 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -146,8 +146,10 @@ struct ipu_ic {
const struct ic_task_regoffs *reg;
const struct ic_task_bitfields *bit;
- enum ipu_color_space in_cs, g_in_cs;
- enum ipu_color_space out_cs;
+ struct ipu_ic_colorspace in_cs;
+ struct ipu_ic_colorspace g_in_cs;
+ struct ipu_ic_colorspace out_cs;
+
bool graphics;
bool rotation;
bool in_use;
@@ -235,42 +237,83 @@ static const struct ic_encode_coeff
ic_encode_ycbcr2rgb_601 = {
.scale = 2,
};
+static int calc_csc_coeffs(struct ipu_ic_priv *priv,
+ struct ic_encode_coeff *coeff_out,
+ const struct ipu_ic_colorspace *in,
+ const struct ipu_ic_colorspace *out)
+{
+ bool inverse_encode;
+
+ if (in->colorspace != out->colorspace) {
+ dev_err(priv->ipu->dev, "Cannot convert colorspaces\n");
+ return -ENOTSUPP;
+ }
I don't think this is useful enough to warrant having the colorspace
field in ipu_ic_colorspace. Let the caller make sure of this, same as
for xfer_func.
Ok, for xfer_func it is implicit that the gamma function must be the
same for input and output, so I agree it might as well be implicit for
chromaticities too.
+ if (out->enc != V4L2_YCBCR_ENC_601) {
+ dev_err(priv->ipu->dev, "Only BT.601 encoding supported\n");
+ return -ENOTSUPP;
+ }
This is only important if out->cs is IPUV3_COLORSPACE_YUV, right? If the
output is RGB this field shouldn't matter.
It matters for encoding YUV to RGB, or the inverse RGB to YUV. The
encoding standard doesn't matter only if no encoding/inverse encoding is
requested (YUV to YUV or RGB to RGB).
+
+ if ((in->cs == IPUV3_COLORSPACE_YUV &&
+in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
+ (out->cs == IPUV3_COLORSPACE_YUV &&
+out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
+ dev_err(priv->ipu->dev, "Limited range YUV not supported\n");
+ return -ENOTSUPP;
+ }
+
+ if ((in->cs == IPUV3_COLORSPACE_RGB &&
+in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
+ (out->cs == IPUV3_COLORSPACE_RGB &&
+out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
+ dev_err(priv->ipu->dev, "Limited range RGB not supported\n");
+ return -ENOTSUPP;
+ }
+
+ if (in->cs == out->cs) {
+ *coeff_out = ic_encode_identity;
+
+ return 0;
+ }
+
+ inverse_encode = (in->cs == IPUV3_COLORSPACE_YUV);
What does inverse_encode mean in this context?
It means YUV to RGB. At this point in the function it is determined that
encoding or inverse encoding is requested.
+
+ *coeff_out = inverse_encode ?
+ ic_encode_ycbcr2rgb_601 : ic_encode_rgb2ycbcr_601;
+
+ return 0;
+}
+
static int init_csc(struct ipu_ic *ic,
- enum ipu_color_space inf,
- enum ipu_color_space outf,
+ const struct ipu_ic_colorspace *in,
+ const struct ipu_ic_colorspace *out,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
- const struct ic_encode_coeff *coeff;
+ struct ic_encode_coeff coeff;
I understand this is a preparation for patch 5, but on its own this
introduces an unnec
[PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()
Using is_zero_ether_addr() instead of directly use
memcmp() to determine if the ethernet address is all
zeros.
Signed-off-by: Mao Wenan
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 714f7a70ed64..beae367df93b 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -180,9 +180,8 @@ struct wlan_network *rtw_find_network(struct __queue
*scanned_queue, u8 *addr)
{
struct list_head *phead, *plist;
struct wlan_network *pnetwork = NULL;
- u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
- if (!memcmp(zero_addr, addr, ETH_ALEN)) {
+ if (is_zero_ether_addr(addr)) {
pnetwork = NULL;
goto exit;
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
