the new standard/hardware decides to use 0x7 for 100mA (hypothetically)?
So, please use switch cases or other robust methods.
--
With Best Regards,
Andy Shevchenko
LE_MASK : 0);
Why not positive conditional?
enable ? 0 : mask
> +}
...
> + ret = devm_add_action_or_reset(dev, mt6370_unregister_tcpci_port,
> + priv->tcpci);
I believe nothing bad will happen if you put it on one line.
--
With Best Regards,
Andy Shevchenko
x1E0
> +
> +#define MT6370_VENID_MASK GENMASK(7, 4)
> +
> +#define MT6370_NUM_IRQREGS 16
> +#define MT6370_USBC_I2CADDR0x4E
> +#define MT6370_REG_ADDRLEN 2
> +#define MT6370_REG_MAXADDR 0x1FF
These two more logically to have near to other _REG_* definitions above.
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 18, 2022 at 10:08 AM ChiYuan Huang wrote:
> On Fri, Jul 15, 2022 at 03:10:42PM +0200, Andy Shevchenko wrote:
> > On Fri, Jul 15, 2022 at 1:28 PM ChiaEn Wu wrote:
...
> > > This commit add support for the Type-C & Power Delivery controller in
> >
ret = fwnode_property_read_u32(init_data->fwnode, "led-max-microamp",
> + );
One line?
...
> + val = clamp_align(val, MT6370_STRBTO_MIN_US,
> MT6370_STRBTO_MAX_US,
> + MT6370_STRBTO_STEP_US);
I would name it mt6370_clamp() to avoid potential collision in the
global namespace in the future.
--
With Best Regards,
Andy Shevchenko
"led %d, no color specified\n",
> + led->index);
> + return ret;
return dev_err_probe(...) ; ?
Ditto for many places in your entire series.
> + }
...
> + priv = devm_kzalloc(>dev,
> + struct_size(priv, leds, count), GFP_KERNEL);
At least one parameter can be placed on the previous line.
> + if (!priv)
> + return -ENOMEM;
--
With Best Regards,
Andy Shevchenko
+ cancel_delayed_work_sync(>mivr_dwork);
> + flush_workqueue(priv->wq);
> + destroy_workqueue(priv->wq);
> + mutex_destroy(>attach_lock);
> +
> + return ret;
> +}
> +
> +static int mt6370_chg_remove(struct platform_device *pdev)
> +{
> + struct mt6370_priv *priv = platform_get_drvdata(pdev);
> +
> + cancel_delayed_work_sync(>mivr_dwork);
> + flush_workqueue(priv->wq);
> + destroy_workqueue(priv->wq);
> + mutex_destroy(>attach_lock);
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
gt;
> I propose, instead:
>
> enum mt6370_state {
> STATE_OFF = 0,
> STATE_KEEP,
> STATE_ON,
> STATE_MAX,
Usually we don't put commas at the terminator entries.
> };
--
With Best Regards,
Andy Shevchenko
nice
to have a temporary variable
struct device *dev = >dev;
It will shorten some lines.
> + struct mt6370_adc_data *priv;
> + struct iio_dev *indio_dev;
> + struct regmap *regmap;
> + int ret;
> +}
--
With Best Regards,
Andy Shevchenko
ot;);
> + }
> +
> + device_init_wakeup(dev, true);
> + dev_pm_set_wake_irq(dev, priv->irq);
> +
> + return 0;
> +}
> +
> +static int mt6370_tcpc_remove(struct platform_device *pdev)
> +{
> + struct mt6370_priv *priv = platform_get_drvdata(pdev);
> + disable_irq(priv->irq);
Why?
An ugly workaround due to ordering issues in ->probe()?
> + tcpci_unregister_port(priv->tcpci);
> + dev_pm_clear_wake_irq(>dev);
> + device_init_wakeup(>dev, false);
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
iver, display bias
> voltage supply, one general purpose LDO, and the USB Type-C & PD controller
> complies with the latest USB Type-C and PD standards.
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: ChiYuan Huang
> ---
> v5
>
> - Add the comma in the last REGM
On Thu, Jul 14, 2022 at 11:43 AM Andy Shevchenko
wrote:
> On Thu, Jul 14, 2022 at 11:27 AM Andy Shevchenko
> wrote:
> > On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > > Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
...
> > > * prop_val = 1 --> 1
On Thu, Jul 14, 2022 at 11:47 AM Daniel Thompson
wrote:
>
> On Thu, Jul 14, 2022 at 11:27:07AM +0200, Andy Shevchenko wrote:
> > On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > > I have tried two metho
On Thu, Jul 14, 2022 at 11:27 AM Andy Shevchenko
wrote:
>
> On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
...
> > I have tried two methods
On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
> > On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu wrote:
> > > Andy Shevchenko 於 2022年7月5日 週二 清晨5:14寫道：
> > > > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu wrote:
Pleas
On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu wrote:
> Andy Shevchenko 於 2022年7月5日 週二 清晨5:14寫道：
> > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu wrote:
Please, remove unneeded context when replying!
...
> > > + brightness_val[0] = (brightness - 1) &
>
return -EINVAL;
> + }
...
> +static int mt6370_bl_probe(struct platform_device *pdev)
> +{
> + struct mt6370_priv *priv;
> + struct backlight_properties props = {
> + .type = BACKLIGHT_RAW,
> + .scale = BACKLIGHT_SCALE_LINEAR,
> + };
> + int ret;
struct device *dev = >dev;
will save you a few LoCs.
--
With Best Regards,
Andy Shevchenko
t;led_no);
> + return PTR_ERR(led->v4l2_flash);
> + }
> +
> + return 0;
> +}
...
> + } else
> + val = clamp_align(val, MT6370_STRBTO_MINUS,
> MT6370_STRBTO_MAXUS,
> + MT6370_STRBTO_STEPUS);
Missed {}
> +
> +
One blank line is enough.
--
With Best Regards,
Andy Shevchenko
priv->attach = pwr_rdy;
> + mutex_unlock(>attach_lock);
> +
> + if (!queue_work(priv->wq, >bc12_work))
> + dev_err(priv->dev, "bc12 work has already queued\n");
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
device pointer.
> +}
...
> +MODULE_DESCRIPTION("MT6370 ADC Drvier");
Driver. Spell check your patches.
--
With Best Regards,
Andy Shevchenko
0, 0, "mediatek,mt6370-charger"),
> + MFD_CELL_OF("backlight", NULL, NULL, 0, 0,
> "mediatek,mt6370-backlight"),
> + MFD_CELL_OF("flashlight", NULL, NULL, 0, 0,
> "mediatek,mt6370-flashlight"),
> + MFD_CELL_OF("indicator", NULL, NULL, 0, 0,
> "mediatek,mt6370-indicator"),
> + MFD_CELL_OF("tcpc", NULL, NULL, 0, 0, "mediatek,mt6370-tcpc"),
> + MFD_CELL_RES("regulator", mt6370_regulator_irqs)
Leave a comma here.
> +};
--
With Best Regards,
Andy Shevchenko
urn dev_err_probe(dev, ...);
Ditto for the rest.
...
> + ret = mt6370_check_vendor_info(priv);
> + if (ret)
> + return dev_err_probe(>dev, ret,
> + "Failed to check vendor info\n");
This duplicates (with less info given) the message from the callee.
...
> + { .compatible = "mediatek,mt6370-tcpc", },
Inner comma is not needed.
--
With Best Regards,
Andy Shevchenko
rt5645.c | 4 +---
> sound/soc/codecs/rt5663.c | 4 +---
> sound/soc/codecs/rt5670.c | 4 +---
> sound/soc/codecs/rt5677.c | 4 +---
> sound/soc/codecs/rt5682
On Fri, Jun 24, 2022 at 12:33 PM ChiaEn Wu wrote:
> Andy Shevchenko 於 2022年6月24日 週五 凌晨2:19寫道：
> > On Thu, Jun 23, 2022 at 2:00 PM ChiaEn Wu wrote:
...
> We got a notification from Mark telling us that this patch has been
> applied to git.
> (
> https://lore.kernel
On Fri, Jun 24, 2022 at 12:19 PM ChiaEn Wu wrote:
> Andy Shevchenko 於 2022年6月24日 週五 凌晨2:01寫道：
> > On Thu, Jun 23, 2022 at 1:59 PM ChiaEn Wu wrote:
...
> > > obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> > > obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)
+probe_out:
> + destroy_workqueue(priv->wq);
> + mutex_destroy(>attach_lock);
I don't see clearly the initialization of these in the ->probe().
Besides that, does destroy_workque() synchronize the actual queue(s)?
Mixing devm_ and non-devm_ may lead to a wrong release order that's
why it is better to see allocating and destroying resources in one
function (they may be wrapped, but should be both of them, seems like
you have done it only for the first parts).
> + return ret;
> +}
...
> +static int mt6370_chg_remove(struct platform_device *pdev)
> +{
> + struct mt6370_priv *priv = platform_get_drvdata(pdev);
> +
> + if (priv) {
Can you describe when this condition can be false?
> + mt6370_chg_enable_irq(priv, "mivr", false);
> + cancel_delayed_work_sync(>mivr_dwork);
> + destroy_workqueue(priv->wq);
> + mutex_destroy(>attach_lock);
> + }
> +
> + return 0;
> +}
...
> +static struct platform_driver mt6370_chg_driver = {
> + .probe = mt6370_chg_probe,
> + .remove = mt6370_chg_remove,
> + .driver = {
> + .name = "mt6370-charger",
> + .of_match_table = of_match_ptr(mt6370_chg_of_match),
No good use of of_match_ptr(), please drop it.
> + },
> +};
--
With Best Regards,
Andy Shevchenko
!regmap) {
> + dev_err(>dev, "Failed to get regmap\n");
> + return -ENODEV;
return dev_err_probe(...);
> + }
...
> + ret = regmap_write(priv->regmap, MT6370_REG_CHG_ADC, 0);
> + if (ret) {
> + dev_err(>dev, "Failed to reset ADC\n");
> + return ret;
> + }
Ditto.
--
With Best Regards,
Andy Shevchenko
"Failed to register (%d) regulator\n", i);
> + return PTR_ERR(rdev);
return dev_err_probe(...); ?
> + }
> +
> + priv->rdev[i] = rdev;
> + }
...
> + if (!priv->regmap) {
> + dev_err(>dev, "Failed to init regmap\n");
> + return -ENODEV;
> + }
return dev_err_probe(...);
--
With Best Regards,
Andy Shevchenko
dev_err(>dev, "Failed to register tcpci port\n");
> + return PTR_ERR(priv->tcpci);
return dev_err_probe(); ?
> + }
...
> + if (ret) {
> + dev_err(>dev, "Failed to allocate irq (%d)\n", ret);
> + tcpci_unregister_port(priv->tcpci);
> + return ret;
Ditto.
> + }
--
With Best Regards,
Andy Shevchenko
= u8_buf[1];
?
...
> + if (ret < 0)
> + return ret;
> + else if (ret != val_size)
Redundant 'else'.
> + return -EIO;
...
> + bank_idx = *(u8 *)data;
> + bank_addr = *(u8 *)(data + 1);
As per above.
--
With Best Regards,
Andy Shevchenko
so contained.)
Even easier, you may take a message-id from the Link and supply to `b4`:
b4 mbox ${message-id}
mutt -f ${message-id}.mbx # or whatever MUA that handles mboxes
Dunno if `b4` has capability to parse Link instead of message-id.
--
With Best Regards,
Andy Shevchenko
>
> Instead of manually checking the power state in struct
> backlight_properties, use backlight_is_blank().
Reviewed-by: Andy Shevchenko
> Signed-off-by: Stephen Kitt
> Cc: Greg Kroah-Hartman
> Cc: "Noralf Trønnes"
> Cc: Thomas Zimmermann
> Cc: Andy Shevche
On Thu, Jun 2, 2022 at 3:57 PM Andy Shevchenko
wrote:
> On Thu, Jun 2, 2022 at 2:07 PM szuni chen wrote:
> > Andy Shevchenko 於 2022年6月1日 週三 下午5:57寫道：
> > > On Tue, May 31, 2022 at 1:32 PM ChiaEn Wu wrote:
...
> > > > + const char * c
On Thu, Jun 2, 2022 at 2:07 PM szuni chen wrote:
> Andy Shevchenko 於 2022年6月1日 週三 下午5:57寫道：
> > On Tue, May 31, 2022 at 1:32 PM ChiaEn Wu wrote:
...
> > > + const char * const states[] = { "off", "keep", "on" };
>
On Thu, Jun 2, 2022 at 8:27 AM ChiYuan Huang wrote:
> On Wed, Jun 01, 2022 at 11:48:58AM +0200, Andy Shevchenko wrote:
> > On Tue, May 31, 2022 at 1:16 PM ChiaEn Wu wrote:
...
> > What indicator?
> It's RGB curent sink type LED driver (maximum supported current is only 24mA).
gt; + if (!count || count > MT6370_MAX_LEDS) {
> + dev_err(>dev,
> + "No child node or node count over max led number %lu\n",
> count);
> + return -EINVAL;
return dev_err_probe(...);
> + }
--
With Best Regards,
Andy Shevchenko
On Wed, Jun 1, 2022 at 11:48 AM Andy Shevchenko
wrote:
> On Tue, May 31, 2022 at 1:16 PM ChiaEn Wu wrote:
> >
> > From: Alice Chen
>
> All below comments are applicable to the rest of the series as well
> (one way or another), so please fix all your patches where it'
mt6372_tfreqs[] = {
> + 8000, 4000, 2000, 1000, 500, 250, 8, 4
Ditto.
> +};
--
With Best Regards,
Andy Shevchenko
ps), GFP_KERNEL);
> + const fbops = devm_kzalloc(dev, sizeof(struct fb_ops), GFP_KERNEL);
Why?
--
With Best Regards,
Andy Shevchenko
);
> MODULE_AUTHOR("Javier Martinez Canillas ");
> MODULE_LICENSE("GPL v2");
> +MODULE_IMPORT_NS(DRM_SSD130X);
--
With Best Regards,
Andy Shevchenko
sport protocols such as SPI.
...
> +EXPORT_SYMBOL_GPL(ssd130x_variants);
What I meant is to use EXPORT_SYMBOL_NS_GPL() here. It might require a separate
patch to move other exports to that namespace first.
--
With Best Regards,
Andy Shevchenko
On Tue, Apr 12, 2022 at 02:21:08PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
> > On 4/12/22 09:23, Geert Uytterhoeven wrote:
> > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> > > wrote:
is, but also with the non-NULL pointers I prefer the old
style without ugly castings.
Instead, you may export the array (in the driver's namespace) and use
[ID] pointer for the specific device info.
--
With Best Regards,
Andy Shevchenko
On Fri, Apr 08, 2022 at 03:54:13PM +0200, Maxime Ripard wrote:
> On Fri, Mar 18, 2022 at 04:33:19PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 18, 2022 at 03:21:45PM +0100, Maxime Ripard wrote:
> > > On Fri, Mar 18, 2022 at 03:42:48PM +0200, Andy Shevchenko wrote:
> >
> >> + return ERR_PTR(ret);
> >> + }
Missed DMA mapping error check.
> >> +
> >> + return >sg_table;
> >> +}
...
> >> - /* Must not be accessed outside the core. */
> >> - struct kref kref;
> >> + struct dma_buf *dmabuf;
Is it okay to access outside the core? If no, why did you remove
(actually not modify) the comment?
--
With Best Regards,
Andy Shevchenko
gt; + * @bytes_used:number of bytes used in this DMABUF for the data
> transfer.
> + * If zero, the full buffer is used.
Wouldn't be error prone to have 0 defined like this?
--
With Best Regards,
Andy Shevchenko
t; +int iio_dma_buffer_write(struct iio_buffer *buffer, size_t n,
> +const char __user *user_buffer)
> +{
> + return iio_dma_buffer_io(buffer, n, (__force char *)user_buffer,
> true);
Why do you drop address space markers?
> +}
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 18, 2022 at 03:21:45PM +0100, Maxime Ripard wrote:
> On Fri, Mar 18, 2022 at 03:42:48PM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 17, 2022 at 12:39:57PM +0100, Javier Martinez Canillas wrote:
> > > On 3/17/22 09:18, Geert Uytterhoeven wrote:
> >
>
ally work? I tried and no one replied to request.
Keeping silent is a bad service. If people don't want a person
to have such access it should be well communicated.
--
With Best Regards,
Andy Shevchenko
It's obvious that we don't and shouldn't modify buffer that
is about to be dumped. Constify parameter in fbtft_dbg_hex()
to make it clear.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Andy Shevchenko
---
v2: new patch to fix a warning (Greg)
drivers/staging/f
fbtft: Remove all strcpy() uses")
Signed-off-by: Andy Shevchenko
---
v2: no changes, just based on prerequisite
drivers/staging/fbtft/fbtft-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-co
On Mon, Mar 14, 2022 at 06:28:41PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
...
> Any reason you didn't test build this?
My test build doesn't include the WERROR for this driver, so I missed the
warning. Sorry for that. Now
clk_prepare_enable() and devm_add_action()) convinces me, that introducing the
> function family is sensible. (And if you want to work on these drivers,
> grepping for devm_clk_get_enabled gives you a few candidates once the
> series is in :-)
FWIW,
Reviewed-by: Andy Shevchenko
for driver
On Tue, Mar 15, 2022 at 12:07:07PM +0100, Geert Uytterhoeven wrote:
> As the temporary buffer is no longer used to store 8-bit grayscale data,
> its size can be reduced to the size needed to store the monochrome
> bitmap data.
bitmap API?
--
With Best Regards,
Andy Shevchenko
byte per pixel for the whole frame buffer, while it only needs to hold
> one bit per pixel for the part that is to be updated.
> Pass dst_pitch to drm_fb_xrgb_to_mono_reversed(), as we have already
> calculated it anyway.
Can we use bitmap API? bitmap_zalloc() / etc ?
--
With Best Regards,
Andy Shevchenko
te |= BIT(i);
> > }
> > *dst++ = byte;
> > }
--
With Best Regards,
Andy Shevchenko
on a text console with a font
> that is 8 pixels wide.
>
> Drop the confusing comment about scanlines, as a pitch in bytes always
> contains a multiple of 8 pixels.
>
> While at it, use the drm_rect_height() helper instead of open-coding the
> same operation.
>
> Update the
ng.
W/ or w/o the below remark being addressed
Reviewed-by: Andy Shevchenko
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/gpu/drm/drm_format_helper.c | 32 ++-
On Tue, Mar 08, 2022 at 11:46:32AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 08, 2022 at 12:18:25PM +0200, Andy Shevchenko wrote:
> > +Cc: Helge
> >
> > Maybe you can pick this up?
> >
> > On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
&g
+Cc: Helge
Maybe you can pick this up?
On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
> In the fbtft_init_display() the init sequence is printed for
> the debug purposes. Unfortunately the current code doesn't take
> into account that values in the buffer are of the
fbtft: Remove all strcpy() uses")
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/fbtft-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 4a35347b3020..b28a059ad
On Tue, Feb 15, 2022 at 07:14:49PM +0200, Jani Nikula wrote:
> On Tue, 15 Feb 2022, Andy Shevchenko
> wrote:
> > It's hard to parse for-loop which has some magic calculations inside.
> > Much cleaner to use while-loop directly.
>
> I assume you're trying to prove a po
It's hard to parse for-loop which has some magic calculations inside.
Much cleaner to use while-loop directly.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/selftests/i915_syncmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Mon, Feb 14, 2022 at 01:12:48PM +0100, Thomas Zimmermann wrote:
> Am 14.02.22 um 11:38 schrieb Andy Shevchenko:
> > On Mon, Feb 14, 2022 at 10:03:53AM +0100, Thomas Zimmermann wrote:
> > > Am 11.02.22 um 16:41 schrieb Andy Shevchenko:
...
> > > > > IMO *alw
On Mon, Feb 14, 2022 at 10:03:53AM +0100, Thomas Zimmermann wrote:
> Am 11.02.22 um 16:41 schrieb Andy Shevchenko:
...
> > > IMO *always* prefer a for loop over while or do-while.
> > >
> > > The for (i = 0; i < N; i++) is such a strong paradigm in C. You
&g
On Mon, Feb 14, 2022 at 11:17:11AM +0200, Pekka Paalanen wrote:
> On Fri, 11 Feb 2022 19:27:12 +0200
> Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 06:25:17PM +0200, Jani Nikula wrote:
> > > On Fri, 11 Feb 2022, Andy Shevchenko
> > > wrote:
> > &g
With Best Regards,
Andy Shevchenko
your fbtft patches to fbdev maintainer as well.
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 11, 2022 at 06:25:17PM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Andy Shevchenko
> wrote:
> > On Fri, Feb 11, 2022 at 02:05:56PM +0200, Jani Nikula wrote:
> >> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> >> > Am 11.02.22 um 12:12 schrie
ocate DRM device\n");
> + return ssd130x;
This...
> + }
...
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x,
> + _bl_ops, NULL);
> + if (IS_ERR(bl))
> + return ERR_PTR(dev_err_probe(dev, PTR_ERR(bl),
> + "Unable to register backlight
> device\n"));
Can be consistent with this then.
--
With Best Regards,
Andy Shevchenko
nditionals from the loop), but since it's almost a direct copy
of the existing code let's improve it later on.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Thomas Zimmermann
> ---
>
> Changes in v5:
> - Use drm_WARN_ON* macros ins
critical, so
Reviewed-by: Andy Shevchenko
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Thomas Zimmermann
> ---
>
> Changes in v5:
> - Add Thomas Zimmermann's Reviewed-by to patch #1.
>
> Changes in v3:
> - Add a drm_fb_xrgb88
On Fri, Feb 11, 2022 at 12:50:04PM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 12:10, Andy Shevchenko wrote:
...
> >> + for (xb = 0; xb < pixels; xb++) {
> >> + unsigned int start = 0, end = 8;
> >> + u8 byte = 0x00;
> >
>
On Fri, Feb 11, 2022 at 01:05:57PM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 12:33, Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 10:19:24AM +0100, Javier Martinez Canillas wrote:
...
> >> + * Helper to write command (SSD130X_COMMAND). The fist
On Fri, Feb 11, 2022 at 02:05:56PM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> > Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
> >> On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
> >>> On 2/11/2
ther maintainer of the binding, to make sure that I will
> be on Cc when patches are proposed for it.
Reviewed-by: Andy Shevchenko
> Suggested-by: Sam Ravnborg
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Rob Herring
> ---
>
> Changes in v4:
> - Add Rob Herring Acked-
nce the new DRM driver was made compatible with the existing binding.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Sam Ravnborg
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Adapt MAINTAINERS entry to point to the n
k;
> + }
> + data_array[array_idx++] = data;
> + }
> + }
...
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x,
> + _bl_ops, NULL);
> + if (IS_ERR(bl)) {
> + ret = PTR_ERR(bl);
> + dev_err_probe(dev, ret, "Unable to register backlight
> device\n");
> + return ERR_PTR(ret);
dev_err_probe(dev, PTR_ERR(bl), "Unable to register backlight
device\n");
return bl;
?
> + }
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 11, 2022 at 10:19:25AM +0100, Javier Martinez Canillas wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over I2C.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Javier
On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 11:28, Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wrote:
...
> >> +static void drm_fb_xrgb_to_gray8_line(u8 *dst, const u32 *src,
art and end pixels that
> + * are not aligned to multiple of 8.
> + *
> + * Calculate if the start and end pixels are not aligned and set the
> + * offsets for the reversed mono line conversion function to adjust.
> + */
> + start_offset = clip->x1 % 8;
> + end_len = clip->x2 % 8;
ALIGN() ?
--
With Best Regards,
Andy Shevchenko
8 b = *src & 0x00ff;
> +
> + /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
> + *dst++ = (3 * r + 6 * g + b) / 10;
> + src++;
> + }
Can be done as
while (pixels--) {
...
}
or
do {
%
>
> With unsorted page lists:
>
> BENCHMARKs: VC: 31.005s VO: 42.889s A: 0.000s Sys: 2.256s = 76.150s
> BENCHMARK%: VC: 40.7156% VO: 56.3219% A: 0.% Sys: 2.9625% = 100.%
>
> VC shows the overhead of video decoding, VO shows the overhead of the
> vide
On Wed, Feb 09, 2022 at 05:26:00PM +0100, Javier Martinez Canillas wrote:
> On 2/9/22 17:08, Andy Shevchenko wrote:
...
> On that topic, I even typed a SPI driver because of your feedback :)
Much appreciated, makes me much easier to test.
Thank you for doing all this!
--
With Best R
different buses, can't clash).
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 09, 2022 at 05:07:03PM +0100, Javier Martinez Canillas wrote:
> On 2/9/22 16:17, Andy Shevchenko wrote:
> > On Wed, Feb 09, 2022 at 01:25:46PM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Feb 9, 2022 at 10:12 AM Javier Martinez Ca
On Wed, Feb 09, 2022 at 04:54:01PM +0100, Javier Martinez Canillas wrote:
> On 2/9/22 16:12, Andy Shevchenko wrote:
> > On Wed, Feb 09, 2022 at 10:03:10AM +0100, Javier Martinez Canillas wrote:
...
> >> + do {
> >> + value = va_arg(ap, int);
> >> +
urrection discussion I can send a new version
to unorphan it, route via fbdev, and leave under staging, so it will be a
compromise between all stakeholders.
--
With Best Regards,
Andy Shevchenko
body keep an eye each rc cycle. It might take time to return it in shape
first.
*) Speaking out of my own experience with device(s) that I possess.
--
With Best Regards,
Andy Shevchenko
may be a good time to deprecate the existing
> "solomon,ssd130*fb-i2c" compatible values, and switch to
> "solomon,ssd130*fb" instead, for both I2C and SPI.
Agree!
> Of course the I2C subdriver still has to bind against the old values,
> too, for backwards compatibility.
--
With Best Regards,
Andy Shevchenko
h Best Regards,
Andy Shevchenko
illas
s?!
...
> +#include
> +#include
regmap.h ?
err.h?
...
> + ssd130x = ssd130x_probe(>dev, regmap);
> +
Redundant blank line.
> + if (IS_ERR(ssd130x))
> + return PTR_ERR(ssd130x);
...
> + { /* sentinel */ },
No comma for terminator entry.
--
With Best Regards,
Andy Shevchenko
return ssd130x;
return dev_err_probe() ?
> + }
...
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x,
> + _bl_ops, NULL);
> + if (IS_ERR(bl)) {
> + ret = PTR_ERR(bl);
> + dev_err(dev, "Unable to register backlight device: %d\n", ret);
> + return ERR_PTR(ret);
Ditto.
> + }
...
> + ret = drm_dev_register(drm, 0);
> + if (ret) {
> + dev_err(dev, "DRM device register failed: %d\n", ret);
> + return ERR_PTR(ret);
Ditto.
> + }
...
I have feelings that half of my comments were ignored...
Maybe I missed the discussion(s).
--
With Best Regards,
Andy Shevchenko
, Geert, for testing and reporting this issue in particular.
--
With Best Regards,
Andy Shevchenko
On Fri, Feb 04, 2022 at 08:19:12PM +0100, Javier Martinez Canillas wrote:
> On 2/4/22 15:26, Andy Shevchenko wrote:
> > On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote:
...
> >> +struct ssd130x_device {
> >> + struct drm
On Fri, Feb 04, 2022 at 03:12:17PM +0100, Javier Martinez Canillas wrote:
> On 2/4/22 14:57, Andy Shevchenko wrote:
> > On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote:
...
> > Stray change?
>
> Sigh, I'm not sure how added that change. Jus
et = PTR_ERR(bl);
> + dev_err(dev, "Unable to register backlight device: %d\n", ret);
> + return ret;
return dev_err_probe();
> + }
...
> + ret = drm_dev_register(drm, 0);
> + if (ret) {
> + dev_err(dev, "DRM device register failed: %d\n", ret);
> + return ret;
> + }
Ditto.
...
> + {},
Comma is not needed in terminator entry.
...
> +static struct i2c_driver ssd130x_i2c_driver = {
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = ssd130x_of_match,
> + },
> + .probe_new = ssd130x_probe,
> + .remove = ssd130x_remove,
> + .shutdown = ssd130x_shutdown,
> +};
> +
Redundant blank line.
> +module_i2c_driver(ssd130x_i2c_driver);
--
With Best Regards,
Andy Shevchenko
nce the new DRM driver was made compatible with the existing binding.
...
> drivers/gpu/drm/drm_format_helper.c | 2 +-
Nothing about this in the commit message...
Stray change?
--
With Best Regards,
Andy Shevchenko
On Wed, Feb 02, 2022 at 12:54:32PM +0100, Javier Martinez Canillas wrote:
> On 2/2/22 12:50, Andy Shevchenko wrote:
> >> What's your suggestion then to solve the issue mentioned above ? With my
> >> distro
> >> maintainer hat I don't care that much, since the fbdev
On Wed, Feb 02, 2022 at 12:39:29PM +0100, Javier Martinez Canillas wrote:
> On 2/2/22 12:06, Andy Shevchenko wrote:
> > On Wed, Feb 02, 2022 at 09:38:51AM +0100, Javier Martinez Canillas wrote:
> >> On 2/1/22 21:40, Sam Ravnborg wrote:
> > And how will distros c
401 - 500 of 959 matches
Mail list logo
