f the standard values for the commands. The controller can
> do parallel, SPI and I2C, but the display I have is wired for I2C.
It looks very similar to ssd1306. Some description refers to ssd1308.
--
With Best Regards,
Andy Shevchenko
___
dri-deve
On Sun, Jul 30, 2017 at 9:27 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Sat, Jul 29, 2017 at 10:17 PM, David Lechner <da...@lechnology.com> wrote:
>> Once all of this is done, it is really easy to add a new panel. :-)
>
> Perhaps pathes are goo
display rather than copying a bunch of boiler-plate code for each
> panel and/or controller.
>
> Once all of this is done, it is really easy to add a new panel. :-)
Perhaps pathes are good, but logically completely incorrect.
--
With Best Regards,
Andy Shevchenko
_
el.txt | 2 +-
> drivers/gpu/drm/tinydrm/mipi-panel.c | 87
> ++\]
C'mon, changes here have nothing to do with the framework itself!
Header, OTOH, has been looking fine.
--
With Best Regards,
Andy Shevchenko
___
dri-d
ke more
generic in the first place? Then you will not need to spread some
stuff
over generic files.
Are we going to disrupt genericy of the framework already with second driver?!
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing
= MIPI_DCS_WRITE_MEMORY_START && !mipi->swap_bytes &&
> + mipi->pixel_fmt != MIPI_DCS_PIXEL_FMT_ST7586_332)
Ditto.
If we allow this we end up to have 100500 LOCs in tinydrm-helpers.c
which will have nothing to do with the framework itself.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
L_FMT_3BIT = 1,
> +};
May I ask what prevents us to arrange enums in natural
ordering (you may keep = X parts, of course)?
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
lt n
> help
> Support for Intel Classmate PC ACPI devices, including some
> @@ -1000,6 +1001,7 @@ config SAMSUNG_Q10
> tristate "Samsung Q10 Extras"
> depends on ACPI
> select BACKLIGHT_CLASS_DEVICE
> + select BACKLIGHT_LCD
) & AMD_141b_MMIO_HIGH_MMIOBASE_MASK) |
> ^~
>arch/x86/pci/fixup.c:687:21: warning: right shift count >= width of type
> [-Wshift-count-overflow]
> res->end + 1) >> 40) << AMD_141b_MMIO_HIGH_MMIOLIMIT_SH
On Sun, Jun 11, 2017 at 3:20 AM, Joe Perches <j...@perches.com> wrote:
> On Sat, 2017-06-10 at 19:12 +0300, Andy Shevchenko wrote:
>> On Wed, May 31, 2017 at 2:35 AM, Joe Perches <j...@perches.com> wrote:
>> > Using the extension saves a bit of code.
>> >
buf[0x9] >> 4, buf[0x9] & 0xf, buf[0xa], buf[0xb]);
Matter of taste, though buf[9], buf[10], buf[11] looks better to me :-)
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jun 9, 2017 at 11:59 AM, Christian König
<deathsim...@vodafone.de> wrote:
> From: Christian König <christian.koe...@amd.com>
>
> This way we can savely call it on SI as well.
s/savely/safely
FWIW,
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
>
On Thu, May 4, 2017 at 1:15 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Thu, May 4, 2017 at 12:23 PM, Christian König
> <deathsim...@vodafone.de> wrote:
>> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
> static int ...xxx...(...)
> {
>
On Thu, May 4, 2017 at 12:23 PM, Christian König
<deathsim...@vodafone.de> wrote:
> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
>>> + while (1) {
>>
>> This raises red flag. Care to refactor?
>> Also do {} while () syntax allows faster to get that
On Tue, May 2, 2017 at 6:51 PM, Christian König <deathsim...@vodafone.de> wrote:
> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
>> On Tue, Apr 25, 2017 at 4:19 PM, Christian König
>> <deathsim...@vodafone.de> wrote:
>>> +int pci_reassign_bridge_resources(s
XX_MASK GENMASK(...)
#define PCI_AMD_BAR_XXX_SHIFT nn
> + pci_write_config_dword(dev, 0x180 + i * 0x4, high);
> + pci_write_config_dword(dev, 0x84 + i * 0x8, limit);
> + pci_write_config_dword(dev, 0x80 + i * 0x8, base);
Ditto for pos:s.
> +
> + pci_bus_add_resource(dev->bus, res, 0);
> +}
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
rt = 0;
> + res->flags |= IORESOURCE_UNSET;
> + dev_info(>dev, "BAR %d: released %pR\n", resno, res);
Makes little sense to me after you cleared information out.
> +}
> +EXPORT_SYMBOL(pci_release_resource);
> +
> +int pci_resize_resource(struct pci_dev *dev, int resno, int size)
> +{
> + struct resource *res = dev->resource + resno;
> + u64 bytes = 1ULL << (size + 20);
> + res->end = res->start + (1ULL << (old + 20)) - 1;
Perhaps macro or helper?
static inline u64 rbar_size_to_bytes(size)
{
return 1ULL << (size + 20);
}
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
EBAR_CTRL, ctrl);
> + return 0;
> + }
> +
> + return -ENOENT;
> +}
> -#define PCI_REBAR_CTRL_NBAR_MASK (7 << 5) /* mask for # bars */
> -#define PCI_REBAR_CTRL_NBAR_SHIFT 5 /* shift for # bars */
> +#define PCI_REBAR
m.
> 3. Fail if any BAR is still in use when we try to change it.
> 4. Handle intermediate bridges as well.
> 5. Print some more messages when changing something.
>
> Please review and/or comment,
Would look later (perhaps this week),
--
With Best Regards,
Andy Shevchenko
t 'select THERMAL'
> from INTEL_MENLOW, so no other driver uses that statement.
>
For PDx86 part:
Acked-by: Andy Shevchenko <andy.shevche...@gmail.com>
> Fixes: bcdfb5e56dc5 ("drm/etnaviv: add etnaviv cooling device")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
&g
);
> + }
> +
> + /* Reinit the doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
Comment why it's used here.
--
With Best Regards,
Andy Shevchenko
_
kfree(res);
> + return;
> + }
> +
> + base = ((res->start >> 8) & 0xff00) | 0x3;
> + limit = ((res->end + 1) >> 8) & 0xff00;
> + high = ((res->start >> 40) & 0xff) |
>
gt; + return -ENOTSUPP;
> +
> + if (!(sizes & (1 << size)))
BIT(size) ?
> + return -EINVAL;
> +
and
old = pci_rbar_get_current_size(dev, resno);
here
> + if (old < 0)
> + return old;
> +error_resize:
> + pc
[5/5] of this series, barring any objections.
>
> I'll move the apple-gmux patch to the end of the series, so merging that
> one can be postponed until Darren and Andy find the time to look at it.
Yeah, please resend. It's probably buried in the pile of deleted mails.
Tho
On Sun, 2017-02-26 at 22:45 +0100, Daniel Vetter wrote:
> On Tue, Feb 21, 2017 at 06:52:24PM +0200, Andy Shevchenko wrote:
> > On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> > > On Tue, 21 Feb 2017, Andy Shevchenko <andriy.shevche...@linux.inte
>
=512GB).
> + * Returns true if resizing was successful, false otherwise.
> + */
> +bool pci_rbar_set_size(struct pci_dev *pdev, int bar, int size)
I would return int and error code. It would be better in the future
and seems in alignment with above.
> +{
> + int pos, nbars;
&g
d).", r);
> + }
> +
> + /* Reinit the doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
No way to recover?!
> +}
> +
--
With Best Regards,
Andy Shevchenko
",
> (uint32_t)adev->doorbell.base);
> + DRM_INFO("doorbell mmio base: 0x%llX\n",
> (uint64_t)adev->doorbell.base);
> DRM_INFO("doorbell mmio size: %u\n", (unsigned)adev->doorbell.size);
It seems I sent patch to remove thos
On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Andy Shevchenko <andriy.shevche...@linux.intel.co
> m> wrote:
> > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> > support") enables GPIO support for Broxton bas
Kahola <mika.kah...@intel.com>
Cc: Jani Nikula <jani.nik...@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i9
t; + * tinydrm_machine_little_endian - Machine is little endian
> + *
> + * Returns:
> + * true if *defined(__LITTLE_ENDIAN)*, false otherwise
> + */
> +static inline bool tinydrm_machine_little_endian(void)
> +{
> +#if defined(__LITTLE_ENDIAN)
> + return true;
> +#else
> + return false;
> +#endif
> +}
Hmm... What is the typical code of a caller for this?
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ret = drm_simple_display_pipe_init(drm, >pipe, funcs, formats,
> + format_count, connector);
> + if (ret)
> + return ret;
> +
> + return 0;
return drm_... ?
> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_init);
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
tatic void reset_semaphore(struct dw_i2c_dev
> > *dev)
> data &= ~PUNIT_SEMAPHORE_BIT;
> if (iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE,
> PUNIT_SEMAPHORE, data))
> dev_err(dev->dev, "iosf failed to reset punit
> semaphore during write\n");
&g
On Sun, 2017-01-08 at 16:30 +0100, Hans de Goede wrote:
> Hi,
>
> On 08-01-17 16:16, Andy Shevchenko wrote:
> > On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> > > One some systems the punit accesses the pmic to change various
> > > voltages
> >
tatic void vlv_set_power_well(struct
> drm_i915_private *dev_priv,
> Â Â Â state,
> Â Â Â vlv_punit_read(dev_priv,
> PUNIT_REG_PWRGT_CTRL));
> Â
> + iosf_mbi_punit_unlock();
> +
> Â #undef COND
> Â
> Â out:
> @@ -1643,6 +1648,8 @@ static void chv_set_pipe_power_well(struct
> drm_i915_private *dev_priv,
> Â if (COND)
> Â goto out;
> Â
> + iosf_mbi_punit_lock();
> +
> Â ctrl = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> Â ctrl &= ~DP_SSC_MASK(pipe);
> Â ctrl |= enable ? DP_SSC_PWR_ON(pipe) : DP_SSC_PWR_GATE(pipe);
> @@ -1653,6 +1660,8 @@ static void chv_set_pipe_power_well(struct
> drm_i915_private *dev_priv,
> Â Â Â state,
> Â Â Â vlv_punit_read(dev_priv,
> PUNIT_REG_DSPFREQ));
> Â
> + iosf_mbi_punit_unlock();
> +
> Â #undef COND
> Â
> Â out:
--
Andy Shevchenko
Intel Finland Oy
> @@ -62,6 +62,8 @@ static void reset_semaphore(struct dw_i2c_dev *dev)
> + iosf_mbi_punit_unlock();
> @@ -79,6 +81,8 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev
> + iosf_mbi_punit_lock();
For me it looks a bit asymmetrical.
Can we use acquire()/release()?
--
Andy Shevchenko
Intel Finland Oy
On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire /
> release.
>
FWIW:
Reviewed-by: Andy Shevchenko
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Test
m other stakeholders that's
_the_ way we are going.
So, FWIW:
Reviewed-by: Andy Shevchenko
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
>  arch/x86/include/asm/iosf_mbi.h    | 54
> +
.
I'm fine with the patch, but please spell
P-Unit
PMIC
Reviewed-by: Andy Shevchenko
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
>  arch/x86/include/asm/iosf_mbi.h    | 31
>
matching
> DRM-based driver is available for the same hardware. However, if there
> is no DRM-based support for a given piece of hardware supported by
> fbtft, I'd prefer if we kept the fbtft driver for this hardware.
Too many people are playing with big things, I vote +1 to *leave*
fbtft for people who prefer small on big.
--
With Best Regards,
Andy Shevchenko
.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/radeon/radeon_device.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 60a8920..67cd59a 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
On Mon, Jul 4, 2016 at 1:40 PM, Lukas Wunner wrote:
> Convert asciidoc-formatted docs to rst in accordance with Jonathan's and
> Jani's effort to use sphinx for kernel-doc rendering in 4.8.
Darren, I'm fine with this one. FWIW:
Reviewed-by: Andy Shevchenko
>
> Cc: Jonathan Corbet
On Fri, 2016-02-26 at 16:11 +0200, Andy Shevchenko wrote:
> On Thu, 2016-02-18 at 01:03 +0100, Rafael J. Wysocki wrote:
> >
> > On Wednesday, February 17, 2016 02:17:24 PM Andy Shevchenko wrote:
> > >
> > > Switch to use a generic UUID API instead of
Instead of opencoding the existing library functions let's use them directly.
The conversion fixes a potential bug in int340x_thermal as well since we have
to use memcmp() on binary data.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_extlog.c| 8 +++---
drivers
in the series.
This also moves indices arrays to lib/uuid.c to be shared accross modules.
Signed-off-by: Andy Shevchenko
---
include/linux/uuid.h | 13 ++
lib/uuid.c | 70
lib/vsprintf.c | 9 +++
3 files changed, 87
constants after conversion).
So, please test this as much as you can and provide your tag. We appreciate the
effort.
Andy Shevchenko (10):
lib/vsprintf: simplify UUID printing
lib/uuid: move generate_random_uuid() to uuid.c
lib/uuid: introduce few more generic helpers for UUID
lib/uuid
On Tue, Feb 9, 2016 at 10:11 PM, Rasmus Villemoes
wrote:
> The current code fails to call i2c_del_adapter on
> dev_prev->gmbus[0].adapter, and if the for loop above failed already
> at i==0, all hell breaks loose when we do the loop body for
> i = -1,-2,...
>
Reviewed-b
On Fri, Jan 29, 2016 at 5:51 PM, Andy Shevchenko
wrote:
> On Fri, Jan 29, 2016 at 5:38 PM, Andy Shevchenko
> wrote:
>> On Thu, Jan 7, 2016 at 5:46 PM, Tomeu Vizoso
>> wrote:
>>> Adds a function that sets the pointer to dev_pm_domain in struct device
>>> and
On Fri, Jan 29, 2016 at 5:38 PM, Andy Shevchenko
wrote:
> On Thu, Jan 7, 2016 at 5:46 PM, Tomeu Vizoso
> wrote:
>> Adds a function that sets the pointer to dev_pm_domain in struct device
>> and that warns if the device has already finished probing. The reason
>>
reak;
This looks wrong. I didn't test yet, but I have concerns here. Why did
you add those calls?
Have you been aware about the commit b5f88dd1d6ef ("Revert "ACPI /
LPSS: allow to use specific PM domain during ->probe()") ?
Sorry for being too late with this.
--
With Best Regards,
Andy Shevchenko
unsigned int count)
> +{
> + while (count--) {
> + pr_debug("unregistering platform driver %ps\n",
> drivers[count]);
> + platform_driver_unregister(drivers[count]);
> + }
> +}
> +EXPORT_SYMBOL_GPL(platform_unregister_drivers);
--
With Best Regards,
Andy Shevchenko
We have to check pointer before usage.
Reported-by: Andrey Karpov
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/nouveau/core/subdev/clock/base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c
b/drivers/gpu/drm
On Mon, 2014-09-08 at 18:28 -0400, Alex Deucher wrote:
> On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko
> wrote:
> > There is no need to use hex_dump_to_buffer() since we have a kernel helper
> > to
> > dump up to 64 bytes just via printk(). In our case the actu
There is no need to use hex_dump_to_buffer() since we have a kernel helper to
dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/radeon/atombios_dp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions
There is no need to use hex_dump_to_buffer() since we have a kernel helper to
dump up to 64 bytes just via printk(). In our case the actual size is 15 bytes.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/radeon/atombios_dp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions
There is no need to pass constants via stack. The width may be explicitly
specified in the format.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu/drm/udl/udl_main.c
There is no need to pass constants via stack. The width may be explicitly
specified in the format.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
drivers/gpu
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/gpu/drm/nouveau/nouveau_dp.c |4 +---
drivers/gpu/drm/radeon/atombios_dp.c |4 +---
drivers/gpu/drm/udl/udl_main.c |7 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/nouveau/nouveau_dp.c |4 +---
drivers/gpu/drm/radeon/atombios_dp.c |4 +---
drivers/gpu/drm/udl/udl_main.c |7 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b
901 - 959 of 959 matches
Mail list logo
