* [PATCH v2 1/5] gxt4500: enable on non-PPC architectures
From: Ondrej Zary @ 2015-10-01 21:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: =Tomi Valkeinen, linux-fbdev, Kernel development list
In-Reply-To: <1443734575-12468-1-git-send-email-linux@rainbow-software.org>
These chips can be present at least on x86 too - Fire GL2 AGP has GXT6000P but
this driver is currently limited to PPC.
Enable it for all architectures and add chip configuration for little-endian.
Tested on x86 with Fire GL2 AGP.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/Kconfig | 5 +++--
drivers/video/fbdev/gxt4500.c | 7 +++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8b1d371..10ff920 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2132,7 +2132,7 @@ config FB_UDL
config FB_IBM_GXT4500
tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
- depends on FB && PPC
+ depends on FB
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2140,7 +2140,8 @@ config FB_IBM_GXT4500
Say Y here to enable support for the IBM GXT4000P/6000P and
GXT4500P/6500P display adaptor based on Raster Engine RC1000,
found on some IBM System P (pSeries) machines. This driver
- doesn't use Geometry Engine GT1000.
+ doesn't use Geometry Engine GT1000. This driver also supports
+ AGP Fire GL2/3/4 cards on x86.
config FB_PS3
tristate "PS3 GPU framebuffer driver"
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index f19133a..ae68696 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -670,8 +670,15 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, info);
+#ifdef __BIG_ENDIAN
/* Set byte-swapping for DFA aperture for all pixel sizes */
pci_write_config_dword(pdev, CFG_ENDIAN0, 0x333300);
+#else /* __LITTLE_ENDIAN */
+ /* not sure what this means but fgl23 driver does that */
+ pci_write_config_dword(pdev, CFG_ENDIAN0, 0x2300);
+/* pci_write_config_dword(pdev, CFG_ENDIAN0 + 4, 0x400000);*/
+ pci_write_config_dword(pdev, CFG_ENDIAN0 + 8, 0x98530000);
+#endif
info->fbops = &gxt4500_ops;
info->flags = FBINFO_FLAG_DEFAULT;
--
Ondrej Zary
^ permalink raw reply related
* [PATCH v2 0/5] [resend] gxt4500: Make usable on x86 and fix some bugs
From: Ondrej Zary @ 2015-10-01 21:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: =Tomi Valkeinen, linux-fbdev, Kernel development list
Fire GL2 AGP has GXT6000P and is a x86 card but the gxt4500 driver is
currently limited to PPC.
This patch series makes the driver work on x86, fixes some color problems
and enhances performance.
^ permalink raw reply
* Re: [PATCH] Revert "backlight: pwm: Handle EPROBE_DEFER while requesting the PWM"
From: Robert Jarzmik @ 2015-10-01 17:39 UTC (permalink / raw)
To: Nicolas Ferre, Boris BREZILLON, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
In-Reply-To: <560CE816.1060307@atmel.com>
Nicolas Ferre <nicolas.ferre@atmel.com> writes:
> Le 30/09/2015 21:29, Robert Jarzmik a écrit :
>> Robert Jarzmik <robert.jarzmik@free.fr> writes:
>>
>>> This reverts commit 68feaca0b13e453aa14ee064c1736202b48b342f.
>>> This commit breaks legacy platforms, for which :
>>> (a) no pwm table is added (legacy platforms)
>>> (b) in this case, in pwm_get(), pmw_lookup_list is empty, and therefore
>>> chosen = NULL, and therefore pwm_get() returns NULL, and pwm_get()
>>> returns -EPROBE_DEFER
>>> (c) as a consequence, this code is unreachable in pwm_bl.c :
>>> if (IS_ERR(pb->pwm)) {
>>> ret = PTR_ERR(pb->pwm);
>>> dev_info(&pdev->dev, "%s:%d(): %d\n", __func__, __LINE__, ret);
>>> if (ret = -EPROBE_DEFER)
>>> goto err_alloc;
>>>
>>> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
>>> pb->legacy = true;
>>> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
>>>
>>> As this code is unreachable, all legacy platforms relying on pwm_id are
>>> broken, amongst which pxa have been tested as broken.
>>>
>>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> Thierry, would you have a look please ?
>> As I said before, all legacy platform relying on pwm_id are broken. I'd like to
>> be sure this lands in the next -rc series.
>
> Otherwise, Boris proposed this fix:
> 8<-----------------------------------------------------------
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index eff379b..00483d4 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -273,15 +273,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->pwm = devm_pwm_get(&pdev->dev, NULL);
> if (IS_ERR(pb->pwm)) {
> ret = PTR_ERR(pb->pwm);
> - if (ret = -EPROBE_DEFER)
> - goto err_alloc;
>
> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
> pb->legacy = true;
> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
> if (IS_ERR(pb->pwm)) {
> dev_err(&pdev->dev, "unable to request legacy PWM\n");
> - ret = PTR_ERR(pb->pwm);
> + if (ret != -EPROBE_DEFER)
> + ret = PTR_ERR(pb->pwm);
> +
> goto err_alloc;
> }
> }
>
> which is not tested and may add an extra non-valid error log.
Now it is tested, and it works correctly AFAICS.
So could you or Borris post this patch, with :
Fixes: 68feaca0b13e ("backlight: pwm: Handle EPROBE_DEFER while requesting the PWM")
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
That would be a good replacement for the revert. Maybe stable tree should be
joined too ...
Cheers.
--
Robert
^ permalink raw reply
* [PATCH RFC V2 1/5] video: hdmi: add helper function for N and CTS
From: Arnaud Pouliquen @ 2015-10-01 16:50 UTC (permalink / raw)
To: alsa-devel, dri-devel
Cc: moinejf, linux-fbdev, linux, bcousson, David Airlie,
tomi.valkeinen, arnaud.pouliquen, lgirdwood, Jyri Sarha,
peter.ujfalusi, Takashi Iwai, tony, broonie, Benjamin Gaignard,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1443718221-5120-1-git-send-email-arnaud.pouliquen@st.com>
Add helper function to compute HDMI CTS and N parameters
Implementation is based on HDMI 1.4b specification.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/hdmi.c | 147 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/hdmi.h | 12 +++++
2 files changed, 159 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..93e2fdf 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1242,3 +1242,150 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer)
return ret;
}
EXPORT_SYMBOL(hdmi_infoframe_unpack);
+
+/**
+ * audio clock regeneration (acr) parameters
+ * N and CTS computation are based on HDMI specification 1.4b
+ */
+enum audio_rate {
+ HDMI_AUDIO_N_CTS_32KHZ,
+ HDMI_AUDIO_N_CTS_44_1KHZ,
+ HDMI_AUDIO_N_CTS_48KHZ,
+};
+
+struct hdmi_audio_acr {
+ unsigned long pixel_clk;
+ struct hdmi_audio_n_cts n_cts;
+};
+
+static const struct hdmi_audio_acr hdmi_audio_standard_acr[3][12] = {
+ { /*32 kHz*/
+ { 25175, { 4576, 28125 } }, /* 25,20/1.001 MHz */
+ { 25200, { 4096, 25200 } }, /* 25.20 MHz */
+ { 27000, { 4096, 27000 } }, /* 27.00 MHz */
+ { 27027, { 4096, 27027 } }, /* 27.00*1.001 MHz */
+ { 54000, { 4096, 54000 } }, /* 54.00 MHz */
+ { 54054, { 4096, 54054 } }, /* 54.00*1.001 MHz */
+ { 74176, { 11648, 310938 } }, /* 74.25/1.001 MHz */
+ { 74250, { 4096, 74250 } }, /* 74.25 MHz */
+ { 148352, { 11648, 421875 } }, /* 148.50/1.001 MHz */
+ { 148500, { 4096, 148500 } }, /* 148.50 MHz */
+ { 296703, { 5824, 421875 } }, /* 297/1.001 MHz */
+ { 297000, { 3072, 222750 } }, /* 297 MHz */
+ },
+ { /*44.1 kHz, 88.2 kHz 176.4 kHz*/
+ { 25175, { 7007, 31250 } }, /* 25,20/1.001 MHz */
+ { 25200, { 6272, 28000 } }, /* 25.20 MHz */
+ { 27000, { 6272, 30000 } }, /* 27.00 MHz */
+ { 27027, { 6272, 30030 } }, /* 27.00*1.001 MHz */
+ { 54000, { 6272, 60000 } }, /* 54.00 MHz */
+ { 54054, { 6272, 60060 } }, /* 54.00*1.001 MHz */
+ { 74176, { 17836, 234375 } }, /* 74.25/1.001 MHz */
+ { 74250, { 6272, 82500 } }, /* 74.25 MHz */
+ { 148352, { 8918, 234375 } }, /* 148.50/1.001 MHz */
+ { 148500, { 6272, 165000 } }, /* 148.50 MHz */
+ { 296703, { 4459, 234375 } }, /* 297/1.001 MHz */
+ { 297000, { 4704, 247500 } }, /* 297 MHz */
+ },
+ { /*48 kHz, 96 kHz 192 kHz*/
+ { 25175, { 6864, 28125 } }, /* 25,20/1.001 MHz */
+ { 25200, { 6144, 25200 } }, /* 25.20 MHz */
+ { 27000, { 6144, 27000 } }, /* 27.00 MHz */
+ { 27027, { 6144, 27027 } }, /* 27.00*1.001 MHz */
+ { 54000, { 6144, 54000 } }, /* 54.00 MHz */
+ { 54054, { 6144, 54054 } }, /* 54.00*1.001 MHz */
+ { 74176, { 11648, 140625 } }, /* 74.25/1.001 MHz */
+ { 74250, { 6144, 74250 } }, /* 74.25 MHz */
+ { 148352, { 5824, 140625 } }, /* 148.50/1.001 MHz */
+ { 148500, { 6144, 148500 } }, /* 148.50 MHz */
+ { 296703, { 5824, 281250 } }, /* 297/1.001 MHz */
+ { 297000, { 5120, 247500 } }, /* 297 MHz */
+ }
+};
+
+/**
+ * hdmi_compute_n_cts() - compute N and CTS parameters
+ * @audio_fs: audio frame clock frequency in KHz
+ * @pixel_clk: pixel cloack frequency in kHz
+ * @n_cts: N and CTS parameter returned to user
+ *
+ * Values computed are based on table described in HDMI specification 1.4b
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_audio_compute_n_cts(enum hdmi_audio_sample_frequency audio_fs,
+ unsigned long pixel_clk,
+ struct hdmi_audio_n_cts *n_cts)
+{
+ int audio_freq_id, i;
+ int ratio = 1;
+ const struct hdmi_audio_acr *acr_table;
+ const struct hdmi_audio_n_cts *predef_n_cts = NULL;
+
+ switch (audio_fs) {
+ case HDMI_AUDIO_SAMPLE_FREQUENCY_32000:
+ audio_freq_id = HDMI_AUDIO_N_CTS_32KHZ;
+ n_cts->n = 4096;
+ break;
+
+ case HDMI_AUDIO_SAMPLE_FREQUENCY_44100:
+ audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
+ n_cts->n = 6272;
+ break;
+
+ case HDMI_AUDIO_SAMPLE_FREQUENCY_48000:
+ audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
+ n_cts->n = 6144;
+ break;
+
+ case HDMI_AUDIO_SAMPLE_FREQUENCY_88200:
+ audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
+ ratio = 2;
+ n_cts->n = 6272 * 2;
+ break;
+
+ case HDMI_AUDIO_SAMPLE_FREQUENCY_96000:
+ audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
+ ratio = 2;
+ n_cts->n = 6144 * 2;
+ break;
+
+ case HDMI_AUDIO_SAMPLE_FREQUENCY_176400:
+ audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
+ ratio = 2;
+ n_cts->n = 6272 * 4;
+ break;
+
+ case HDMI_AUDIO_SAMPLE_FREQUENCY_192000:
+ audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
+ ratio = 4;
+ n_cts->n = 6144 * 4;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ acr_table = hdmi_audio_standard_acr[audio_freq_id];
+ for (i = 0; i < ARRAY_SIZE(hdmi_audio_standard_acr[0]); i++) {
+ if (pixel_clk = acr_table[i].pixel_clk) {
+ predef_n_cts = &acr_table[i].n_cts;
+ break;
+ }
+ }
+
+ if (!predef_n_cts) {
+ /*
+ * predefined frequency not found. Compute CTS using formula:
+ * CTS = (Ftdms_clk * N) / (128* audio_fs)
+ */
+ n_cts->cts = pixel_clk * n_cts->n / (128 * audio_fs);
+ } else {
+ n_cts->n = predef_n_cts->n * ratio;
+ n_cts->cts = predef_n_cts->cts;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_audio_compute_n_cts);
+
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..95c2b12 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -333,4 +333,16 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer);
void hdmi_infoframe_log(const char *level, struct device *dev,
union hdmi_infoframe *frame);
+/**
+ * struct hdmi_audio_n_cts - n and cts parameter for ACR packets
+ */
+struct hdmi_audio_n_cts {
+ unsigned int n;
+ unsigned int cts;
+};
+
+int hdmi_audio_compute_n_cts(enum hdmi_audio_sample_frequency audio_fs,
+ unsigned long pixel_clk,
+ struct hdmi_audio_n_cts *n_cts);
+
#endif /* _DRM_HDMI_H */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] Revert "backlight: pwm: Handle EPROBE_DEFER while requesting the PWM"
From: Robert Jarzmik @ 2015-10-01 9:06 UTC (permalink / raw)
To: Nicolas Ferre, Boris BREZILLON, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
In-Reply-To: <560CE816.1060307@atmel.com>
Nicolas Ferre <nicolas.ferre@atmel.com> writes:
> Le 30/09/2015 21:29, Robert Jarzmik a écrit :
>> Robert Jarzmik <robert.jarzmik@free.fr> writes:
>>
>>> This reverts commit 68feaca0b13e453aa14ee064c1736202b48b342f.
>>> This commit breaks legacy platforms, for which :
>>> (a) no pwm table is added (legacy platforms)
>>> (b) in this case, in pwm_get(), pmw_lookup_list is empty, and therefore
>>> chosen = NULL, and therefore pwm_get() returns NULL, and pwm_get()
>>> returns -EPROBE_DEFER
>>> (c) as a consequence, this code is unreachable in pwm_bl.c :
>>> if (IS_ERR(pb->pwm)) {
>>> ret = PTR_ERR(pb->pwm);
>>> dev_info(&pdev->dev, "%s:%d(): %d\n", __func__, __LINE__, ret);
>>> if (ret = -EPROBE_DEFER)
>>> goto err_alloc;
>>>
>>> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
>>> pb->legacy = true;
>>> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
>>>
>>> As this code is unreachable, all legacy platforms relying on pwm_id are
>>> broken, amongst which pxa have been tested as broken.
>>>
>>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> Thierry, would you have a look please ?
>> As I said before, all legacy platform relying on pwm_id are broken. I'd like to
>> be sure this lands in the next -rc series.
>
> Well, as I answered on the linux-pwm mailing-list (I was not in copy) here:
> http://article.gmane.org/gmane.linux.pwm/2744
> I wonder if it's not easier to fix the platforms and add the pwm tables...
No it's not, at least not for a -rc cycle. It's the long term solution you're
talking about, not the fix one.
> Otherwise, Boris proposed this fix:
> 8<-----------------------------------------------------------
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index eff379b..00483d4 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -273,15 +273,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->pwm = devm_pwm_get(&pdev->dev, NULL);
> if (IS_ERR(pb->pwm)) {
> ret = PTR_ERR(pb->pwm);
> - if (ret = -EPROBE_DEFER)
> - goto err_alloc;
>
> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
> pb->legacy = true;
> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
> if (IS_ERR(pb->pwm)) {
> dev_err(&pdev->dev, "unable to request legacy PWM\n");
> - ret = PTR_ERR(pb->pwm);
> + if (ret != -EPROBE_DEFER)
> + ret = PTR_ERR(pb->pwm);
> +
> goto err_alloc;
> }
> }
>
> which is not tested and may add an extra non-valid error log.
I can test that, today, it looks an interesting alternative.
If both solutions do work, someone (Boris) can post a patch for this -rc instead
of the revert. If no patch is posted, I maintain my Revert, as this patch _does_
break platforms (omap is broken too AFAICS).
Cheers.
--
Robert
PS: I have not received http://article.gmane.org/gmane.linux.pwm/2744.
Is it my mailer or MUA which is broken, ie. was I in the "To:" of the mail ?
PPS: Sorry to having forgotten to join you to the revert
PPPS: As long as an other patch is not submitted to fix the issue (other than
the Revert), I NAK the NAK. There is a breakage introduced, and I consider
it a strong enough reason to be maintained for the -rc serie.
^ permalink raw reply
* Re: [PATCH] Revert "backlight: pwm: Handle EPROBE_DEFER while requesting the PWM"
From: Nicolas Ferre @ 2015-10-01 8:00 UTC (permalink / raw)
To: Robert Jarzmik, Thierry Reding, linux-pwm, Boris BREZILLON,
Alexandre Belloni
Cc: Jingoo Han, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <87bncjemdk.fsf@belgarion.home>
Le 30/09/2015 21:29, Robert Jarzmik a écrit :
> Robert Jarzmik <robert.jarzmik@free.fr> writes:
>
>> This reverts commit 68feaca0b13e453aa14ee064c1736202b48b342f.
>> This commit breaks legacy platforms, for which :
>> (a) no pwm table is added (legacy platforms)
>> (b) in this case, in pwm_get(), pmw_lookup_list is empty, and therefore
>> chosen = NULL, and therefore pwm_get() returns NULL, and pwm_get()
>> returns -EPROBE_DEFER
>> (c) as a consequence, this code is unreachable in pwm_bl.c :
>> if (IS_ERR(pb->pwm)) {
>> ret = PTR_ERR(pb->pwm);
>> dev_info(&pdev->dev, "%s:%d(): %d\n", __func__, __LINE__, ret);
>> if (ret = -EPROBE_DEFER)
>> goto err_alloc;
>>
>> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
>> pb->legacy = true;
>> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
>>
>> As this code is unreachable, all legacy platforms relying on pwm_id are
>> broken, amongst which pxa have been tested as broken.
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Thierry, would you have a look please ?
> As I said before, all legacy platform relying on pwm_id are broken. I'd like to
> be sure this lands in the next -rc series.
Well, as I answered on the linux-pwm mailing-list (I was not in copy) here:
http://article.gmane.org/gmane.linux.pwm/2744
I wonder if it's not easier to fix the platforms and add the pwm tables...
Otherwise, Boris proposed this fix:
8<-----------------------------------------------------------
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index eff379b..00483d4 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -273,15 +273,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm)) {
ret = PTR_ERR(pb->pwm);
- if (ret = -EPROBE_DEFER)
- goto err_alloc;
dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
pb->legacy = true;
pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
if (IS_ERR(pb->pwm)) {
dev_err(&pdev->dev, "unable to request legacy PWM\n");
- ret = PTR_ERR(pb->pwm);
+ if (ret != -EPROBE_DEFER)
+ ret = PTR_ERR(pb->pwm);
+
goto err_alloc;
}
}
which is not tested and may add an extra non-valid error log.
Bye,
--
Nicolas Ferre
^ permalink raw reply related
* Re: [PATCH] Revert "backlight: pwm: Handle EPROBE_DEFER while requesting the PWM"
From: Robert Jarzmik @ 2015-09-30 19:29 UTC (permalink / raw)
To: Thierry Reding, Nicolas Ferre
Cc: Jingoo Han, Lee Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-pwm, linux-fbdev, linux-kernel
In-Reply-To: <1443295482-18687-1-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> This reverts commit 68feaca0b13e453aa14ee064c1736202b48b342f.
> This commit breaks legacy platforms, for which :
> (a) no pwm table is added (legacy platforms)
> (b) in this case, in pwm_get(), pmw_lookup_list is empty, and therefore
> chosen = NULL, and therefore pwm_get() returns NULL, and pwm_get()
> returns -EPROBE_DEFER
> (c) as a consequence, this code is unreachable in pwm_bl.c :
> if (IS_ERR(pb->pwm)) {
> ret = PTR_ERR(pb->pwm);
> dev_info(&pdev->dev, "%s:%d(): %d\n", __func__, __LINE__, ret);
> if (ret = -EPROBE_DEFER)
> goto err_alloc;
>
> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
> pb->legacy = true;
> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
>
> As this code is unreachable, all legacy platforms relying on pwm_id are
> broken, amongst which pxa have been tested as broken.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Thierry, would you have a look please ?
As I said before, all legacy platform relying on pwm_id are broken. I'd like to
be sure this lands in the next -rc series.
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCHv4 1/3] leds: Add of_led_get() and led_put()
From: Jacek Anaszewski @ 2015-09-30 14:29 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jingoo Han, Lee Jones, linux-leds, linux-fbdev, Andrew Lunn
In-Reply-To: <1443605522-1118-2-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Thanks for the update.
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
On 09/30/2015 11:32 AM, Tomi Valkeinen wrote:
> This patch adds basic support for a kernel driver to get a LED device.
> This will be used by the led-backlight driver.
>
> Only OF version is implemented for now, and the behavior is similar to
> PWM's of_pwm_get() and pwm_put().
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/leds/Makefile | 6 +++-
> drivers/leds/led-class.c | 13 +++++++-
> drivers/leds/led-of.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/leds/leds.h | 1 +
> include/linux/leds.h | 10 ++++++
> include/linux/of_leds.h | 26 +++++++++++++++
> 6 files changed, 139 insertions(+), 2 deletions(-)
> create mode 100644 drivers/leds/led-of.c
> create mode 100644 include/linux/of_leds.h
>
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 8d6a24a2f513..6fd22e411810 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -1,7 +1,11 @@
>
> # LED Core
> obj-$(CONFIG_NEW_LEDS) += led-core.o
> -obj-$(CONFIG_LEDS_CLASS) += led-class.o
> +
> +obj-$(CONFIG_LEDS_CLASS) += led-class-objs.o
> +led-class-objs-y := led-class.o
> +led-class-objs-$(CONFIG_OF) += led-of.o
> +
> obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
> obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index beabfbc6f7cd..ff0c27654358 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -22,7 +22,7 @@
> #include <linux/timer.h>
> #include "leds.h"
>
> -static struct class *leds_class;
> +struct class *leds_class;
>
> static ssize_t brightness_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> @@ -216,6 +216,17 @@ static int led_resume(struct device *dev)
>
> static SIMPLE_DEV_PM_OPS(leds_class_dev_pm_ops, led_suspend, led_resume);
>
> +/**
> + * led_put() - release a LED device, reserved with of_led_get()
> + * @led_cdev: LED device
> + */
> +void led_put(struct led_classdev *led_cdev)
> +{
> + put_device(led_cdev->dev);
> + module_put(led_cdev->dev->parent->driver->owner);
> +}
> +EXPORT_SYMBOL_GPL(led_put);
> +
> static int match_name(struct device *dev, const void *data)
> {
> if (!dev_name(dev))
> diff --git a/drivers/leds/led-of.c b/drivers/leds/led-of.c
> new file mode 100644
> index 000000000000..6e96fee9adf1
> --- /dev/null
> +++ b/drivers/leds/led-of.c
> @@ -0,0 +1,85 @@
> +/*
> + * LED Class Core OF support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/leds.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_leds.h>
> +
> +#include "leds.h"
> +
> +/* find OF node for the given led_cdev */
> +static struct device_node *find_led_of_node(struct led_classdev *led_cdev)
> +{
> + struct device *led_dev = led_cdev->dev;
> + struct device_node *child;
> +
> + for_each_child_of_node(led_dev->parent->of_node, child) {
> + int idx;
> +
> + idx = of_property_match_string(child, "label", led_cdev->name);
> + if (idx = 0)
> + return child;
> + }
> +
> + return NULL;
> +}
> +
> +static int led_match_led_node(struct device *led_dev, const void *data)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(led_dev);
> + const struct device_node *target_node = data;
> + struct device_node *led_node;
> +
> + led_node = find_led_of_node(led_cdev);
> + if (!led_node)
> + return 0;
> +
> + of_node_put(led_node);
> +
> + return led_node = target_node;
> +}
> +
> +/**
> + * of_led_get() - request a LED device via the LED framework
> + * @np: device node to get the LED device from
> + *
> + * Returns the LED device parsed from the phandle specified in the "leds"
> + * property of a device tree node or a negative error-code on failure.
> + *
> + * The caller must use led_put() to release the device after use.
> + */
> +struct led_classdev *of_led_get(struct device_node *np)
> +{
> + struct device *led_dev;
> + struct led_classdev *led_cdev;
> + struct device_node *led_node;
> +
> + led_node = of_parse_phandle(np, "leds", 0);
> + if (!led_node)
> + return ERR_PTR(-ENODEV);
> +
> + led_dev = class_find_device(leds_class, NULL, led_node,
> + led_match_led_node);
> +
> + of_node_put(led_node);
> +
> + if (!led_dev) {
> + pr_err("failed to find led device for node %s, deferring probe\n",
> + of_node_full_name(led_node));
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
> + led_cdev = dev_get_drvdata(led_dev);
> +
> + if (!try_module_get(led_cdev->dev->parent->driver->owner))
> + return ERR_PTR(-ENODEV);
> +
> + return led_cdev;
> +}
> +EXPORT_SYMBOL_GPL(of_led_get);
> diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
> index bc89d7ace2c4..ccc3abb417d4 100644
> --- a/drivers/leds/leds.h
> +++ b/drivers/leds/leds.h
> @@ -46,6 +46,7 @@ static inline int led_get_brightness(struct led_classdev *led_cdev)
>
> void led_stop_software_blink(struct led_classdev *led_cdev);
>
> +extern struct class *leds_class;
> extern struct rw_semaphore leds_list_lock;
> extern struct list_head leds_list;
>
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index b122eeafb5dc..fbad4ce78e6e 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -113,6 +113,16 @@ extern void devm_led_classdev_unregister(struct device *parent,
> extern void led_classdev_suspend(struct led_classdev *led_cdev);
> extern void led_classdev_resume(struct led_classdev *led_cdev);
>
> +#if IS_ENABLED(CONFIG_LEDS_CLASS)
> +
> +extern void led_put(struct led_classdev *led_cdev);
> +
> +#else
> +
> +static inline void led_put(struct led_classdev *led_cdev) { }
> +
> +#endif /* IS_ENABLED(CONFIG_LEDS_CLASS) */
> +
> /**
> * led_blink_set - set blinking with software fallback
> * @led_cdev: the LED to start blinking
> diff --git a/include/linux/of_leds.h b/include/linux/of_leds.h
> new file mode 100644
> index 000000000000..7e8e64bd9811
> --- /dev/null
> +++ b/include/linux/of_leds.h
> @@ -0,0 +1,26 @@
> +/*
> + * OF support for leds
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#ifndef __LINUX_LEDS_OF_H_INCLUDED
> +#define __LINUX_LEDS_OF_H_INCLUDED
> +
> +#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_LEDS_CLASS)
> +
> +extern struct led_classdev *of_led_get(struct device_node *np);
> +
> +#else
> +
> +static inline struct led_classdev *of_led_get(struct device_node *np)
> +{
> + return -ENODEV;
> +}
> +
> +#endif
> +
> +#endif /* __LINUX_LEDS_OF_H_INCLUDED */
>
--
Best Regards,
Jacek Anaszewski
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Emil Velikov @ 2015-09-30 11:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David Herrmann, Thomas Petazzoni, linux-fbdev, Teddy Wang,
Daniel Vetter, linux-kernel@vger.kernel.org, DRI Development,
Arnaud Patard, Tomi Valkeinen, Laurent Pinchart,
Greg Kroah-Hartman, Dave Airlie, Sudip Mukherjee
In-Reply-To: <CAMuHMdWdyTay2nX5CFPOUQQjVxFTTcZF=sVaNDziTs6GV2DGqQ@mail.gmail.com>
Hi all,
On 26 September 2015 at 19:46, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi David,
>
> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>> <geert@linux-m68k.org> wrote:
>>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>>> to these existing really simple drivers?
>>>>
>>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>>
>>> Thanks for the list!
>>>
>>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>>> several fbdev drivers that have less than 200 LoC.
>>> Granted, these really small ones support a single fixed video mode only, but
>>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>>
>>> I'm sure DRM can do better?
>>
>> Is counting lines really the level of the discussion to go here?
>
> LoC is not the most important. But if the smallest DRM driver needs an order
> of magnitude more LoC than the smallest fbdev driver, I start to wonder.
>
> E.g. if I want to write a new simple driver for my new shiny hardware, it
> can make a big difference if I have to write (and test/debug) 800 LoC, or
> 3000 LoC.
>
Ftr, the smallest DRM/KMS driver that I could see is the layerscape
(fsl-dcu) one. It is roughly 1.4k LoC which includes ~300 worth of
defines, licence headers and build glue. Admittedly not it's not as
low as 200-800 LoC, but it's an example that they can get smaller, as
helpers in drm core are added. udl has been written quite some time
ago and doesn't make use of atomics, etc. the latter of which should
make things easier/shorter.
Regards,
Emil
^ permalink raw reply
* [PATCH] video: of: fix memory leak
From: Sudip Mukherjee @ 2015-09-30 10:06 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-kernel, linux-fbdev, Sudip Mukherjee
If of_parse_display_timing() fails we are printing an error message and
jumping to the error path but we missed freeing "dt".
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/video/of_display_timing.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index 32d8275..8a1076b 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -210,6 +210,7 @@ struct display_timings *of_get_display_timings(struct device_node *np)
*/
pr_err("%s: error in timing %d\n",
of_node_full_name(np), disp->num_timings + 1);
+ kfree(dt);
goto timingfail;
}
--
1.9.1
^ permalink raw reply related
* [PATCHv4 3/3] devicetree: Add led-backlight binding
From: Tomi Valkeinen @ 2015-09-30 9:32 UTC (permalink / raw)
To: Jacek Anaszewski, Jingoo Han, Lee Jones, linux-leds, linux-fbdev
Cc: Andrew Lunn, Tomi Valkeinen, devicetree
In-Reply-To: <1443605522-1118-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding for led-backlight.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org
---
.../bindings/video/backlight/led-backlight.txt | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/backlight/led-backlight.txt
diff --git a/Documentation/devicetree/bindings/video/backlight/led-backlight.txt b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
new file mode 100644
index 000000000000..d4621d7414bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/led-backlight.txt
@@ -0,0 +1,30 @@
+led-backlight bindings
+
+Required properties:
+ - compatible: "led-backlight"
+ - leds: phandle to a led OF node [0]
+ - brightness-levels: Array of distinct LED brightness levels. These
+ are in the range from 0 to 255, passed to the LED class driver.
+ - default-brightness-level: the default brightness level (index into the
+ array defined by the "brightness-levels" property)
+
+Optional properties:
+ - power-supply: regulator for supply voltage
+ - enable-gpios: contains a single GPIO specifier for the GPIO which enables
+ and disables the backlight (see GPIO binding[1])
+
+[0]: Documentation/devicetree/bindings/leds/common.txt
+[1]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+
+ backlight {
+ compatible = "led-backlight";
+ leds = <&backlight_led>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <&vdd_bl_reg>;
+ enable-gpios = <&gpio 58 0>;
+ };
--
2.1.4
^ permalink raw reply related
* [PATCHv4 2/3] backlight: add led-backlight driver
From: Tomi Valkeinen @ 2015-09-30 9:32 UTC (permalink / raw)
To: Jacek Anaszewski, Jingoo Han, Lee Jones, linux-leds, linux-fbdev
Cc: Andrew Lunn, Tomi Valkeinen
In-Reply-To: <1443605522-1118-1-git-send-email-tomi.valkeinen@ti.com>
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/led_bl.c | 246 +++++++++++++++++++++++++++++++++++++++
3 files changed, 254 insertions(+)
create mode 100644 drivers/video/backlight/led_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 0505b796d743..d1336196aba2 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -453,6 +453,13 @@ config BACKLIGHT_BD6107
help
If you have a Rohm BD6107 say Y to enable the backlight driver.
+config BACKLIGHT_LED
+ tristate "Generic LED based Backlight Driver"
+ depends on LEDS_CLASS && OF
+ help
+ If you have a LCD backlight adjustable by LED class driver, say Y
+ to enable this driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index d67073f9d421..ecd321daee21 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -54,3 +54,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
+obj-$(CONFIG_BACKLIGHT_LED) += led_bl.o
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
new file mode 100644
index 000000000000..1befc8ce5964
--- /dev/null
+++ b/drivers/video/backlight/led_bl.c
@@ -0,0 +1,246 @@
+/*
+ * Copyright 2015 Texas Instruments
+ *
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * Based on pwm_bl.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+#include <linux/backlight.h>
+#include <linux/gpio/consumer.h>
+#include <linux/leds.h>
+#include <linux/of_leds.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+struct led_bl_data {
+ struct device *dev;
+ struct backlight_device *bl_dev;
+
+ unsigned int *levels;
+ bool enabled;
+ struct regulator *power_supply;
+ struct gpio_desc *enable_gpio;
+
+ struct led_classdev *led_cdev;
+
+ unsigned int max_brightness;
+ unsigned int default_brightness;
+};
+
+static void led_bl_set_brightness(struct led_bl_data *priv, int brightness)
+{
+ int err;
+
+ if (!priv->enabled) {
+ if (priv->power_supply) {
+ err = regulator_enable(priv->power_supply);
+
+ if (err < 0)
+ dev_err(priv->dev,
+ "failed to enable power supply\n");
+ }
+
+ if (priv->enable_gpio)
+ gpiod_set_value_cansleep(priv->enable_gpio, 1);
+ }
+
+ led_set_brightness(priv->led_cdev, priv->levels[brightness]);
+
+ priv->enabled = true;
+}
+
+static void led_bl_power_off(struct led_bl_data *priv)
+{
+ if (!priv->enabled)
+ return;
+
+ led_set_brightness(priv->led_cdev, LED_OFF);
+
+ if (priv->enable_gpio)
+ gpiod_set_value_cansleep(priv->enable_gpio, 0);
+
+ if (priv->power_supply)
+ regulator_disable(priv->power_supply);
+
+ priv->enabled = false;
+}
+
+static int led_bl_update_status(struct backlight_device *bl)
+{
+ struct led_bl_data *priv = bl_get_data(bl);
+ int brightness = bl->props.brightness;
+
+ if (bl->props.power != FB_BLANK_UNBLANK ||
+ bl->props.fb_blank != FB_BLANK_UNBLANK ||
+ bl->props.state & BL_CORE_FBBLANK)
+ brightness = 0;
+
+ if (brightness > 0)
+ led_bl_set_brightness(priv, brightness);
+ else
+ led_bl_power_off(priv);
+
+ return 0;
+}
+
+static const struct backlight_ops led_bl_ops = {
+ .update_status = led_bl_update_status,
+};
+
+static int led_bl_parse_dt(struct device *dev,
+ struct led_bl_data *priv)
+{
+ struct device_node *node = dev->of_node;
+ int num_levels;
+ u32 *levels;
+ u32 value;
+ int ret;
+
+ if (!node)
+ return -ENODEV;
+
+ num_levels = of_property_count_u32_elems(node, "brightness-levels");
+ if (num_levels < 0) {
+ dev_err(dev, "failed to find 'brightness-levels'\n");
+ return num_levels;
+ }
+
+ levels = devm_kzalloc(dev, sizeof(u32) * num_levels, GFP_KERNEL);
+ if (!levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(node, "brightness-levels",
+ levels,
+ num_levels);
+ if (ret < 0) {
+ dev_err(dev, "failed to parse 'brightness-levels'\n");
+ return ret;
+ }
+
+ ret = of_property_read_u32(node, "default-brightness-level", &value);
+ if (ret < 0) {
+ dev_err(dev, "failed to parse 'default-brightness-level'\n");
+ return ret;
+ }
+
+ if (value >= num_levels) {
+ dev_err(dev, "invalid default-brightness-level\n");
+ return -EINVAL;
+ }
+
+ priv->levels = levels;
+ priv->max_brightness = num_levels - 1;
+ priv->default_brightness = value;
+
+ priv->led_cdev = of_led_get(node);
+ if (IS_ERR(priv->led_cdev)) {
+ dev_err(dev, "failed to get LED device\n");
+ return PTR_ERR(priv->led_cdev);
+ }
+
+ return 0;
+}
+
+static int led_bl_probe(struct platform_device *pdev)
+{
+ struct backlight_properties props;
+ struct led_bl_data *priv;
+ int ret;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ priv->dev = &pdev->dev;
+
+ ret = led_bl_parse_dt(&pdev->dev, priv);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to parse DT data\n");
+ return ret;
+ }
+
+ priv->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(priv->enable_gpio)) {
+ ret = PTR_ERR(priv->enable_gpio);
+ goto err;
+ }
+
+ priv->power_supply = devm_regulator_get_optional(&pdev->dev, "power");
+ if (IS_ERR(priv->power_supply)) {
+ ret = PTR_ERR(priv->power_supply);
+
+ if (ret = -ENODEV) {
+ priv->power_supply = NULL;
+ } else {
+ ret = PTR_ERR(priv->power_supply);
+ goto err;
+ }
+ }
+
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = priv->max_brightness;
+ priv->bl_dev = backlight_device_register(dev_name(&pdev->dev),
+ &pdev->dev, priv, &led_bl_ops, &props);
+ if (IS_ERR(priv->bl_dev)) {
+ dev_err(&pdev->dev, "failed to register backlight\n");
+ ret = PTR_ERR(priv->bl_dev);
+ goto err;
+ }
+
+ priv->bl_dev->props.brightness = priv->default_brightness;
+ backlight_update_status(priv->bl_dev);
+
+ return 0;
+
+err:
+ if (priv->led_cdev)
+ led_put(priv->led_cdev);
+
+ return ret;
+}
+
+static int led_bl_remove(struct platform_device *pdev)
+{
+ struct led_bl_data *priv = platform_get_drvdata(pdev);
+ struct backlight_device *bl = priv->bl_dev;
+
+ backlight_device_unregister(bl);
+
+ led_bl_power_off(priv);
+
+ led_put(priv->led_cdev);
+
+ return 0;
+}
+
+static const struct of_device_id led_bl_of_match[] = {
+ { .compatible = "led-backlight" },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, led_bl_of_match);
+
+static struct platform_driver led_bl_driver = {
+ .driver = {
+ .name = "led-backlight",
+ .of_match_table = of_match_ptr(led_bl_of_match),
+ },
+ .probe = led_bl_probe,
+ .remove = led_bl_remove,
+};
+
+module_platform_driver(led_bl_driver);
+
+MODULE_DESCRIPTION("LED based Backlight Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:led-backlight");
--
2.1.4
^ permalink raw reply related
* [PATCHv4 1/3] leds: Add of_led_get() and led_put()
From: Tomi Valkeinen @ 2015-09-30 9:32 UTC (permalink / raw)
To: Jacek Anaszewski, Jingoo Han, Lee Jones, linux-leds, linux-fbdev
Cc: Andrew Lunn, Tomi Valkeinen
In-Reply-To: <1443605522-1118-1-git-send-email-tomi.valkeinen@ti.com>
This patch adds basic support for a kernel driver to get a LED device.
This will be used by the led-backlight driver.
Only OF version is implemented for now, and the behavior is similar to
PWM's of_pwm_get() and pwm_put().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/leds/Makefile | 6 +++-
drivers/leds/led-class.c | 13 +++++++-
drivers/leds/led-of.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++
drivers/leds/leds.h | 1 +
include/linux/leds.h | 10 ++++++
include/linux/of_leds.h | 26 +++++++++++++++
6 files changed, 139 insertions(+), 2 deletions(-)
create mode 100644 drivers/leds/led-of.c
create mode 100644 include/linux/of_leds.h
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8d6a24a2f513..6fd22e411810 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -1,7 +1,11 @@
# LED Core
obj-$(CONFIG_NEW_LEDS) += led-core.o
-obj-$(CONFIG_LEDS_CLASS) += led-class.o
+
+obj-$(CONFIG_LEDS_CLASS) += led-class-objs.o
+led-class-objs-y := led-class.o
+led-class-objs-$(CONFIG_OF) += led-of.o
+
obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index beabfbc6f7cd..ff0c27654358 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -22,7 +22,7 @@
#include <linux/timer.h>
#include "leds.h"
-static struct class *leds_class;
+struct class *leds_class;
static ssize_t brightness_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -216,6 +216,17 @@ static int led_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(leds_class_dev_pm_ops, led_suspend, led_resume);
+/**
+ * led_put() - release a LED device, reserved with of_led_get()
+ * @led_cdev: LED device
+ */
+void led_put(struct led_classdev *led_cdev)
+{
+ put_device(led_cdev->dev);
+ module_put(led_cdev->dev->parent->driver->owner);
+}
+EXPORT_SYMBOL_GPL(led_put);
+
static int match_name(struct device *dev, const void *data)
{
if (!dev_name(dev))
diff --git a/drivers/leds/led-of.c b/drivers/leds/led-of.c
new file mode 100644
index 000000000000..6e96fee9adf1
--- /dev/null
+++ b/drivers/leds/led-of.c
@@ -0,0 +1,85 @@
+/*
+ * LED Class Core OF support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_leds.h>
+
+#include "leds.h"
+
+/* find OF node for the given led_cdev */
+static struct device_node *find_led_of_node(struct led_classdev *led_cdev)
+{
+ struct device *led_dev = led_cdev->dev;
+ struct device_node *child;
+
+ for_each_child_of_node(led_dev->parent->of_node, child) {
+ int idx;
+
+ idx = of_property_match_string(child, "label", led_cdev->name);
+ if (idx = 0)
+ return child;
+ }
+
+ return NULL;
+}
+
+static int led_match_led_node(struct device *led_dev, const void *data)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(led_dev);
+ const struct device_node *target_node = data;
+ struct device_node *led_node;
+
+ led_node = find_led_of_node(led_cdev);
+ if (!led_node)
+ return 0;
+
+ of_node_put(led_node);
+
+ return led_node = target_node;
+}
+
+/**
+ * of_led_get() - request a LED device via the LED framework
+ * @np: device node to get the LED device from
+ *
+ * Returns the LED device parsed from the phandle specified in the "leds"
+ * property of a device tree node or a negative error-code on failure.
+ *
+ * The caller must use led_put() to release the device after use.
+ */
+struct led_classdev *of_led_get(struct device_node *np)
+{
+ struct device *led_dev;
+ struct led_classdev *led_cdev;
+ struct device_node *led_node;
+
+ led_node = of_parse_phandle(np, "leds", 0);
+ if (!led_node)
+ return ERR_PTR(-ENODEV);
+
+ led_dev = class_find_device(leds_class, NULL, led_node,
+ led_match_led_node);
+
+ of_node_put(led_node);
+
+ if (!led_dev) {
+ pr_err("failed to find led device for node %s, deferring probe\n",
+ of_node_full_name(led_node));
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ led_cdev = dev_get_drvdata(led_dev);
+
+ if (!try_module_get(led_cdev->dev->parent->driver->owner))
+ return ERR_PTR(-ENODEV);
+
+ return led_cdev;
+}
+EXPORT_SYMBOL_GPL(of_led_get);
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index bc89d7ace2c4..ccc3abb417d4 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -46,6 +46,7 @@ static inline int led_get_brightness(struct led_classdev *led_cdev)
void led_stop_software_blink(struct led_classdev *led_cdev);
+extern struct class *leds_class;
extern struct rw_semaphore leds_list_lock;
extern struct list_head leds_list;
diff --git a/include/linux/leds.h b/include/linux/leds.h
index b122eeafb5dc..fbad4ce78e6e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -113,6 +113,16 @@ extern void devm_led_classdev_unregister(struct device *parent,
extern void led_classdev_suspend(struct led_classdev *led_cdev);
extern void led_classdev_resume(struct led_classdev *led_cdev);
+#if IS_ENABLED(CONFIG_LEDS_CLASS)
+
+extern void led_put(struct led_classdev *led_cdev);
+
+#else
+
+static inline void led_put(struct led_classdev *led_cdev) { }
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS) */
+
/**
* led_blink_set - set blinking with software fallback
* @led_cdev: the LED to start blinking
diff --git a/include/linux/of_leds.h b/include/linux/of_leds.h
new file mode 100644
index 000000000000..7e8e64bd9811
--- /dev/null
+++ b/include/linux/of_leds.h
@@ -0,0 +1,26 @@
+/*
+ * OF support for leds
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __LINUX_LEDS_OF_H_INCLUDED
+#define __LINUX_LEDS_OF_H_INCLUDED
+
+#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_LEDS_CLASS)
+
+extern struct led_classdev *of_led_get(struct device_node *np);
+
+#else
+
+static inline struct led_classdev *of_led_get(struct device_node *np)
+{
+ return -ENODEV;
+}
+
+#endif
+
+#endif /* __LINUX_LEDS_OF_H_INCLUDED */
--
2.1.4
^ permalink raw reply related
* [PATCHv4 0/3] backlight: led-backlight driver
From: Tomi Valkeinen @ 2015-09-30 9:31 UTC (permalink / raw)
To: Jacek Anaszewski, Jingoo Han, Lee Jones, linux-leds, linux-fbdev
Cc: Andrew Lunn, Tomi Valkeinen
This series aims to add a led-backlight driver, similar to pwm-backlight, but
using a LED class device underneath.
LED framework has no support for DT or getting a LED class driver from another
kernel driver, so I added minimal functionality to led-class to get
led-backlight working.
Changes to v3:
- Change a comment to refer to of_led_get()
Changes to v2:
- power supply is now optional
- cosmetic changes
- no-op function for led_put() when !CONFIG_LEDS_CLASS
Changes to v1:
- Split LED OF parts into separate .h and .c files
- Check for CONFIG_OF and CONFIG_LEDS_CLASS where relevant to leave unused code
out.
- Improved error prints and comments a bit
- Added put_device() into led_put(), as the device was gotten from
class_find_device() which requires a put_device() call.
Tomi
Tomi Valkeinen (3):
leds: Add of_led_get() and led_put()
backlight: add led-backlight driver
devicetree: Add led-backlight binding
.../bindings/video/backlight/led-backlight.txt | 30 +++
drivers/leds/Makefile | 6 +-
drivers/leds/led-class.c | 13 +-
drivers/leds/led-of.c | 85 +++++++
drivers/leds/leds.h | 1 +
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/led_bl.c | 246 +++++++++++++++++++++
include/linux/leds.h | 10 +
include/linux/of_leds.h | 26 +++
10 files changed, 423 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/backlight/led-backlight.txt
create mode 100644 drivers/leds/led-of.c
create mode 100644 drivers/video/backlight/led_bl.c
create mode 100644 include/linux/of_leds.h
--
2.1.4
^ permalink raw reply
* Re: [PATCH v2 1/2] fb_ddc: Allow I2C adapters without SCL read capability
From: Tomi Valkeinen @ 2015-09-30 7:55 UTC (permalink / raw)
To: Ondrej Zary, Krzysztof Helt; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1443132854-31786-1-git-send-email-linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
On 25/09/15 01:14, Ondrej Zary wrote:
> i2c-algo-bit allows I2C adapters without SCL read capability to work
> but fb_ddc_read fails to work on them.
>
> Fix fb_ddc_read to work with I2C adapters not capable of reading SCL.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> ---
> drivers/video/fbdev/core/fb_ddc.c | 28 ++++++++++++++++++----------
> 1 file changed, 18 insertions(+), 10 deletions(-)
Thanks, queued this and the 2/2 patch for 4.4.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] fbdev: broadsheetfb: fix memory leak
From: Tomi Valkeinen @ 2015-09-30 7:38 UTC (permalink / raw)
To: Sudip Mukherjee, Jean-Christophe Plagniol-Villard
Cc: linux-kernel, linux-fbdev
In-Reply-To: <1443257530-26848-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
On 26/09/15 11:52, Sudip Mukherjee wrote:
> We have requested the firmware and it was loaded but we missed releasing
> it both on success and error.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Thanks, queued for 4.3 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Laurent Pinchart @ 2015-09-29 8:33 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
Daniel Vetter, linux-kernel@vger.kernel.org, DRI Development,
Tomi Valkeinen, Geert Uytterhoeven, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <1443515003.21557.12.camel@redhat.com>
Hi Gerd,
On Tuesday 29 September 2015 10:23:23 Gerd Hoffmann wrote:
> On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
> > On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > > > those simplifications that would make sense if more such drivers are
> > > > added.
> > >
> > > Another one is memory management. It's pretty complex because it can
> > > handle _way_ more than what simple drivers need, and the result is
> > > _alot_ of ttm boilerplate in the drivers.
> >
> > ttm is pretty impressive overkill for most simplistic drm drivers. If you
> > just need contiguous framebuffers for display then the cma helpers should
> > take care of pretty much all the boilerplate for you. They have ready-made
> > simple gem and dumb framebuffer mmap support, which is all a basic kms
> > driver needs.
>
> Does that work on !arm meanwhile? Last time I checked (when writing
> bochsdrm, around v3.14) the cma helpers didn't even build on x86 ...
config DRM_GEM_CMA_HELPER
bool
depends on DRM && HAVE_DMA_ATTRS
help
Choose this if you need the GEM CMA helper functions
x86 defines HAVE_DMA_ATTRS.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Gerd Hoffmann @ 2015-09-29 8:23 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
Daniel Vetter, linux-kernel@vger.kernel.org, DRI Development,
Tomi Valkeinen, Geert Uytterhoeven, Laurent Pinchart,
Arnaud Patard, Dave Airlie, Sudip Mukherjee
In-Reply-To: <20150928123627.GD3383@phenom.ffwll.local>
On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
> On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > > those simplifications that would make sense if more such drivers are
> > > added.
> >
> > Another one is memory management. It's pretty complex because it can
> > handle _way_ more than what simple drivers need, and the result is
> > _alot_ of ttm boilerplate in the drivers.
>
> ttm is pretty impressive overkill for most simplistic drm drivers. If you
> just need contiguous framebuffers for display then the cma helpers should
> take care of pretty much all the boilerplate for you. They have ready-made
> simple gem and dumb framebuffer mmap support, which is all a basic kms
> driver needs.
Does that work on !arm meanwhile? Last time I checked (when writing
bochsdrm, around v3.14) the cma helpers didn't even build on x86 ...
cheers,
Gerd
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Daniel Vetter @ 2015-09-29 7:07 UTC (permalink / raw)
To: Noralf Trønnes
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
Emil Velikov, linux-kernel@vger.kernel.org, DRI Development,
Tomi Valkeinen, Laurent Pinchart, Daniel Vetter, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <5609C47A.6030809@tronnes.org>
On Tue, Sep 29, 2015 at 12:51:38AM +0200, Noralf Trønnes wrote:
>
> Den 27.09.2015 18:08, skrev Emil Velikov:
> >Hi all,
> >
> >On 27 September 2015 at 14:09, Noralf Trønnes <noralf@tronnes.org> wrote:
> >>Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> >>>Hi all,
> >>>
> >>>fbdev is (more or less) maintained, but it's a deprecated framework. All
> >>>new Linux display drivers should be done on DRM.
> >>>
> >>>So let's not add any more new fbdev drivers.
> >>>
> >>>I will continue to maintain the current fbdev drivers, and I don't mind
> >>>adding some new features to those current drivers, as long as the amount
> >>>of code required to add the features stays sensible.
> >>>
> >>>I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> >>>and the question is what to do with those.
> >>>
> >>>xgifb was added in 2010, and is still in staging.
> >>>
> >>>fbtft looks like maybe some kind of framework on top of fbdev, with
> >>>fbtft specific subdrivers... I didn't look at it in detail, but my gut
> >>>says "never".
> >>
> >>I have done some work [1] to try and make fbtft look more like the rest
> >>of the kernel (doc [2]), but that work will result in an almost complete
> >>rewrite of fbtft.
> > From a very quick skim fbtft looks pretty much like drm/panel. We
> >presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
> >you had a look at these ?
>
> Thanks, that was useful.
> I can use drm_panel to setup the controller (prepare) and do backlight
> (enable/disable), but I need a way to send framebuffer changes.
> I could do this:
>
> struct tinydrm_panel_funcs {
> int (*update)(struct drm_framebuffer *fb,
> struct drm_gem_cma_object *cma_obj,
> unsigned flags, unsigned color,
> struct drm_clip_rect *clips, unsigned num_clips);
> };
>
> struct tinydrm_panel {
> struct drm_panel panel;
> u32 width;
> u32 height;
> void *dev_private;
>
> const struct tinydrm_panel_funcs *funcs;
> };
I'm not sure whether putting the manual-update stuff into drm_panel is a
good idea - it's transport/bus (spi, dsi, ...) specific. Not sure how to
best solve that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Daniel Vetter @ 2015-09-29 7:05 UTC (permalink / raw)
To: Bernie Thompson
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, DRI Development, Arnaud Patard,
Tomi Valkeinen, Geert Uytterhoeven, Laurent Pinchart,
Greg Kroah-Hartman, Dave Airlie, Sudip Mukherjee
In-Reply-To: <CAF1V4O_9LC9QM_AcE7gaV4hp4jcEe47nzKj=CXxvsnH_L=YRYw@mail.gmail.com>
On Mon, Sep 28, 2015 at 01:52:31PM -0700, Bernie Thompson wrote:
> On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven <geert@linux-m68k.org>
> wrote:
> > The smallest of these (udl) still counts in at ca. 2800 LoC,
>
> Note udlfb.c, the original fbdev driver that I helped write and that the
> udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in
> the ballpark of 2x (rather than 10x) between fbdev and DRM in this case.
> That said, the complexity difference is probably higher than the LoC
> difference. I know I personally have struggled in the shift from
> understanding fbdev to understanding DRM.
udl has a bit of room for improvement, we really should push the worker
logicy for fbdev emulation into the core drm fbdev helpers using the
->dirtyfb callback. That should rip out quite a few lines.
The other thing to consider is that drm/udl supports PRIME buffer sharing
for seamlessly extending your desktop by just plugging in an usb dongle.
> The fact that there's drivers of both types and USB hardware might make udl
> may be a good driver to use as a base for any additional simplification /
> helper work. David Airlie and David Herrmann both have this hardware. David
> Airlie did the port from fbdev to DRM, so he's made it an exemplary
> driver. And if anyone needs any hardware which works with udlfb and udl,
> we're happy to send free hardware to any programmers who are willing to
> contribute in the form of code or testing:
> http://plugable.com/projects/plugable-open-source-hardware-samples-program
For example drivers I think it's better to look at the latest drm driver
merged - those are up-to-date wrt best practices. udl has already
accumulated a bit of cruft (e.g. still using legacy modeset helpers and
not the atomic ones).
> More simplification and documentation would be great. In particular, the
> optimization for the connector+encoder+crtc combination others have
> mentioned seems like it would be worthwhile.
Atomic helpers already make almost everything optional except for the
crtc-level enable/disable callbacks and the per-plane atomic_plane_update
(for buffer flips/panning/rotation/...). So a comibined helper would be
mostly for cutting down the structure setup/teardown boilerplate. So
should be fairly easy to implement even for drm beginners (when using one
of the latest drivers as a template for what needs to be done).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Noralf Trønnes @ 2015-09-28 22:51 UTC (permalink / raw)
To: Emil Velikov
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Dave Airlie, Sudip Mukherjee
In-Reply-To: <CACvgo50PpEG3CVBQdMuXEg9TG+mY_Kxnp3OOHMdZ-hxr3Mok5Q@mail.gmail.com>
Den 27.09.2015 18:08, skrev Emil Velikov:
> Hi all,
>
> On 27 September 2015 at 14:09, Noralf Trønnes <noralf@tronnes.org> wrote:
>> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>> Hi all,
>>>
>>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>>> new Linux display drivers should be done on DRM.
>>>
>>> So let's not add any more new fbdev drivers.
>>>
>>> I will continue to maintain the current fbdev drivers, and I don't mind
>>> adding some new features to those current drivers, as long as the amount
>>> of code required to add the features stays sensible.
>>>
>>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>>> and the question is what to do with those.
>>>
>>> xgifb was added in 2010, and is still in staging.
>>>
>>> fbtft looks like maybe some kind of framework on top of fbdev, with
>>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>>> says "never".
>>
>> I have done some work [1] to try and make fbtft look more like the rest
>> of the kernel (doc [2]), but that work will result in an almost complete
>> rewrite of fbtft.
> From a very quick skim fbtft looks pretty much like drm/panel. We
> presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
> you had a look at these ?
Thanks, that was useful.
I can use drm_panel to setup the controller (prepare) and do backlight
(enable/disable), but I need a way to send framebuffer changes.
I could do this:
struct tinydrm_panel_funcs {
int (*update)(struct drm_framebuffer *fb,
struct drm_gem_cma_object *cma_obj,
unsigned flags, unsigned color,
struct drm_clip_rect *clips, unsigned num_clips);
};
struct tinydrm_panel {
struct drm_panel panel;
u32 width;
u32 height;
void *dev_private;
const struct tinydrm_panel_funcs *funcs;
};
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Bernie Thompson @ 2015-09-28 20:56 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, linux-fbdev
In-Reply-To: <CAMuHMdX0Jg9RSu9rm2-trtMCDpS16Zy8VLEnmjvW_vWVWvHdVQ@mail.gmail.com>
On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> The smallest of these (udl) still counts in at ca. 2800 LoC,
Note udlfb.c, the original fbdev driver that I helped write and that
the udl DRM driver was based on, is ~1800 LoC ... so we're actually
talking in the ballpark of 2x (rather than 10x) between fbdev and DRM
in this case. That said, the complexity difference is probably higher
than the LoC difference. I know I personally have struggled in the
shift from understanding fbdev to understanding DRM.
The fact that there's drivers of both types and USB hardware might
make udl may be a good driver to use as a base for any additional
simplification / helper work. David Airlie and David Herrmann both
have this hardware. David Airlie did the port from fbdev to DRM, so
he's made it an exemplary driver. And if anyone needs any hardware
which works with udlfb and udl, we're happy to send free hardware to
any programmers who are willing to contribute in the form of code or
testing: http://plugable.com/projects/plugable-open-source-hardware-samples-program
More simplification and documentation would be great. In particular,
the optimization for the connector+encoder+crtc combination others
have mentioned seems like it would be worthwhile.
Cheers,
Bernie
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Daniel Vetter @ 2015-09-28 12:36 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
Daniel Vetter, linux-kernel@vger.kernel.org, DRI Development,
Tomi Valkeinen, Geert Uytterhoeven, Laurent Pinchart,
Arnaud Patard, Dave Airlie, Sudip Mukherjee
In-Reply-To: <1443425953.19666.6.camel@redhat.com>
On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > those simplifications that would make sense if more such drivers are
> > added.
>
> Another one is memory management. It's pretty complex because it can
> handle _way_ more than what simple drivers need, and the result is
> _alot_ of ttm boilerplate in the drivers.
ttm is pretty impressive overkill for most simplistic drm drivers. If you
just need contiguous framebuffers for display then the cma helpers should
take care of pretty much all the boilerplate for you. They have ready-made
simple gem and dumb framebuffer mmap support, which is all a basic kms
driver needs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCHv3 2/3] backlight: add led-backlight driver
From: Lee Jones @ 2015-09-28 10:31 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jingoo Han, Jacek Anaszewski, linux-leds, linux-fbdev,
Andrew Lunn
In-Reply-To: <5608F66E.8020703@ti.com>
On Mon, 28 Sep 2015, Tomi Valkeinen wrote:
> > This patch adds a led-backlight driver (led_bl), which is similar to
> > pwm_bl except the driver uses a LED class driver to adjust the
> > brightness in the HW.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> > drivers/video/backlight/Kconfig | 7 ++
> > drivers/video/backlight/Makefile | 1 +
> > drivers/video/backlight/led_bl.c | 246 +++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 254 insertions(+)
> > create mode 100644 drivers/video/backlight/led_bl.c
>
> Any comments on the backlight side of this series? It is very similar to
> the pwm_bl.c, so I presume the approach is acceptable?
Jingoo?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCHv3 2/3] backlight: add led-backlight driver
From: Tomi Valkeinen @ 2015-09-28 8:12 UTC (permalink / raw)
To: Jingoo Han, Lee Jones
Cc: Jacek Anaszewski, linux-leds, linux-fbdev, Andrew Lunn
In-Reply-To: <1441976857-26548-3-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
Hi Jingoo, Lee,
On 11/09/15 16:07, Tomi Valkeinen wrote:
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/backlight/Kconfig | 7 ++
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/led_bl.c | 246 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 254 insertions(+)
> create mode 100644 drivers/video/backlight/led_bl.c
Any comments on the backlight side of this series? It is very similar to
the pwm_bl.c, so I presume the approach is acceptable?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox